Se você escreve software para viver em 2018, então posso dizer com segurança que você está familiarizado com o Git. ferramenta criada por Linus Torvalds se tornou sinônimo de controle de versão. E sem dúvida, um dos melhores recursos do Git é como ele tira a dor de ramificação e fusão. Existem várias maneiras de criar um branch no Git. Neste post, revisaremos alguns deles. Em seguida, terminaremos com uma pequena reflexão sobre o modelo de ramificação do Git e ramificações em geral.

Criando um branch do mestre

Você cria branches no Git, sem surpresa, usando o comando branch. Como muitos outros comandos do Git, “branch” é muito poderoso e flexível. Além de criar branches, ele também pode ser usado para listá-los e excluí-los, e você pode personalizar ainda mais o comando empregando uma ampla lista de parâmetros. Começaremos com a primeira maneira de criar um branch. Digamos que você queira criar uma nova pasta chamada “my-app”, entre nela e inicie um novo repositório Git. É exatamente assim que você faria:

mkdir my-appcd my-appgit init

Agora você tem um novo repositório Git vazio. Mas repositórios vazios são entediantes. Então, que tal criar um novo arquivo markdown com “Hello World!” escrito nele?

echo Hello World! > file.md

Se você executar “git status”, deverá ver uma mensagem dizendo que seu arquivo não está rastreado:

Arquivos não rastreados também não são legais, então vamos rastreá-los:

git add file.md

E, finalmente, vamos criar nosso primeiro commit:

git commit -m "First commit"

Agora temos um repositório com um branch, que tem exatamente um commit. Isso pode não soar como o coisa mais empolgante do mundo (porque realmente não é), mas com certeza é menos chato do que ter um repo sem nenhum commit, certo? Agora, digamos que por qualquer motivo você precise alterar o arquivo está contente. Mas você não sinto vontade de fazer isso. E se algo der errado e você estragar o conteúdo bonito e puro do seu arquivo? (Sim, eu sei que é apenas um arquivo estúpido com “Olá, mundo!”, Mas use os maravilhosos poderes de sua imaginação e pense no arquivo como um proxy para um projeto muito mais complexo.) A solução para este dilema está, obviamente, criando um novo branch:

git branch exp

Portanto, agora temos um novo branch chamado “exp”, para experimentação Algumas pessoas que estão acostumadas a usar diferentes sistemas de versionamento, especialmente os centralizados, podem dizer que os branches têm o mesmo “conteúdo”. Isso não é totalmente correto quando falamos sobre Git, no entanto. Pense em branches como referências que apontam para um determinado commit.

Criando um branch a partir de um commit

Suponha que, por qualquer motivo, desistamos de nosso experimento, sem adicionar um único comprometa-se com o novo ramo. Vamos voltar ao master e excluir o branch exp:

git checkout mastergit branch -d exp

Agora que estamos de volta a um único branch, vamos adicionar alguns commits a ele, para simular o trabalho que está sendo feito:

Imagine que depois de fazer todo esse “trabalho”, você aprende que, por qualquer motivo, você precisa voltar no tempo para quando foram apenas duas linhas no arquivo e criar novas alterações a partir de então. Mas ao mesmo tempo, você deve preservar o progresso que já fez. Em outras palavras, você deseja criar um branch de um commit anterior. Como você faria isso ? No Git, cada commit tem um identificador único. Você pode ver isso facilmente usando o comando “git log”. Para criar um novo branch com base em um commit específico, basta passar seu hash como um parâmetro para o comando do branch:

git branch new-branch 7e4decb

À parte, você nem precisa do hash inteiro na maior parte do tempo. Apenas os primeiros cinco ou seis caracteres farão isso.

Criando uma ramificação a partir de uma tag

Se você tem um pouco mais de experiência com Git, deve estar familiarizado com o conceito de tags. Você usa tags para indicar que um determinado commit é importante ou especial de alguma forma. Por exemplo, as tags geralmente são usadas para indicar as versões reais de um produto. Se você trabalha em seu aplicativo há algum tempo e Se você acredita que é hora de lançar a versão 1.0, o que você normalmente faria é aumentar os números da versão sempre que necessário, confirmando essas alterações e, em seguida, adicionando uma tag a esse ponto específico no tempo. Para criar uma tag, você “geralmente executa algo assim:

git tag -a v1.0 -m "First major version"

O parâmetro” -a “indica que isso está acontecendo para ser uma tag anotada. Em contraste com uma tag leve, este é um objeto Git completo, contendo informações como o nome e o e-mail do committer, o timestamp e uma mensagem. Agora você tem uma tag, uma indicação de que esse ponto específico da história é especial e tem um nome. Legal. Você pode continuar trabalhando, como de costume, criando e submetendo as mudanças que farão parte da versão 1.1. Até que um relatório de bug chegue. Alguns clientes que foram atualizados para o 1.A versão 0 do produto diz que um recurso de importação não está funcionando conforme o planejado. Bem, você poderia teoricamente corrigir o bug no branch master e implantá-lo. Mas então os clientes receberiam recursos que são potencialmente não testados e incompletos. Isso é não -não. Então, o que você faz? A resposta: você cria um novo branch a partir da tag que você criou para indicar a versão principal. Você corrige o problema lá, compila e implanta. E provavelmente deve mesclar isso de volta ao master depois, para que as próximas versões contenham a correção . Como você faria isso? Fácil:

git branch <NAME-OF-THE-BRANCH> <TAG>

Mais especificamente, usando nosso exemplo anterior:

git branch fix-bug-123 v1.0

Depois disso, você pode verificar seu novo branch como de costume. Ou melhor ainda, você pode fazer tudo em uma única etapa:

git checkout -b fix-bug-1234 v1.0

Criando uma filial no estado de cabeça destacada

Você já desejou voltar no tempo? Com o Git isso é possível … pelo menos em relação aos arquivos em nosso repositório. Você pode, a qualquer momento, verificar um commit se souber seu hash:

git checkout <SHA1>

Depois de executar isso, o Git mostrará uma mensagem curiosa:

Quando você fizer o check-out um commit, você entra em um estado especial c alled, como você pode ver, “destacou HEAD”. Embora você possa enviar alterações neste estado, esses commits não pertencem a nenhum branch e se tornarão inacessíveis assim que você fizer check-out de outro branch. Mas e se você quiser manter esses commits? A resposta, sem surpresa, é usar o comando “checkout” novamente para criar um novo branch:

git checkout <sha1> #now you"re in detached head state# do some work and stage itgit commit -m "add some work while in detached head state"git branch new-branch-to-keep-commitsgit checkout new-branch-to-keep-commits

E, claro, agora você sabe que pode escrever o últimas duas linhas como um único comando:

git checkout -b new-branch-to-keep-commits

Muito fácil, certo?

Só porque você pode … Não significa que você deveria

O modelo de ramificação do Git é um de seus argumentos de venda. Ele transforma o que em outros sistemas de controle de origem é um processo doloroso e até lento em uma brisa. Pode-se dizer que o Git democratizou com sucesso a ramificação para as massas. Mas existe um sério perigo. Devido ao baixo custo da ramificação no Git, alguns desenvolvedores podem cair na armadilha de trabalhar com ramificações extremamente duradouras ou empregar fluxos de trabalho ou modelos de ramificação que atrasam a integração gração. Nós, como indústria, já estivemos lá. Nós fizemos isso. Não funciona. Em vez disso, adote fluxos de trabalho que empregam ramos de vida extremamente curta. Você terá uma sandbox segura na qual codificar sem medo de quebrar coisas ou perder o tempo de seus colegas de trabalho. Mas isso o faz perguntar: “Como implantar código com recursos parcialmente concluídos?” Nesse caso, são sinalizadores de recursos para o resgate. Os branches do Git são uma ferramenta poderosa. Use-os com sabedoria e não abuse deles. E quando não forem suficientes, empregue entrega / integração contínua junto com sinalizadores de recursos, incluindo ferramentas especializadas à sua disposição, para que seus aplicativos possam chegar ao próximo nível.