3.4 Ramificação (Branching) no Git - Fluxos de Trabalho de Branches (Branching Workflows)

Como o Git usa uma simples mesclagem de três vias (three-way merge), mesclar de um branch para outro várias vezes durante um longo período é geralmente fácil de fazer. Isso significa que você pode ter vários branches que estão sempre abertos e que você usa para diferentes estágios do seu ciclo de desenvolvimento; você pode mesclar (merge) regularmente de alguns deles para outros.

Muitos desenvolvedores Git têm um fluxo de trabalho que adota essa abordagem, como ter apenas código que seja totalmente estável no seu branch master — possivelmente apenas código que foi ou será lançado (released). Eles têm outro branch paralelo chamado develop ou next com o qual trabalham ou usam para testar a estabilidade — não é necessariamente sempre estável, mas sempre que chega a um estado estável, pode ser mesclado (merged) no master. Ele é usado para extrair (pull in) branches de tópicos (branches de curta duração, como seu branch iss53 anterior) quando eles estiverem prontos, para garantir que passem em todos os testes e não introduzam bugs.

Na realidade, estamos falando sobre ponteiros movendo-se na linha de commits que você está fazendo. Os branches estáveis estão mais abaixo na linha do seu histórico de commits, e os branches de ponta (bleeding-edge) estão mais acima no histórico.

Geralmente, é mais fácil pensar neles como silos de trabalho, onde conjuntos de commits se formam para um silo mais estável quando são totalmente testados.

Você pode continuar fazendo isso por vários níveis de estabilidade. Alguns projetos maiores também têm um branch proposed ou pu (atualizações propostas) que integrou branches que podem não estar prontos para ir para o branch next ou master. A ideia é que os seus branches estejam em vários níveis de estabilidade; quando eles atingem um nível mais estável, eles são mesclados (merged) no branch acima deles. Novamente, ter vários branches de longa duração não é necessário, mas costuma ser útil, especialmente quando você está lidando com projetos muito grandes ou complexos.

Os branches de tópicos, no entanto, são úteis em projetos de qualquer tamanho. Um branch de tópico é um branch de curta duração que você cria e usa para um único recurso específico (feature) ou trabalho relacionado. Isso é algo que você provavelmente nunca fez com um VCS (Sistema de Controle de Versão) antes, porque geralmente é muito caro criar e mesclar branches. Mas no Git é comum criar, trabalhar, mesclar e excluir branches várias vezes ao dia.

Você viu isso na última seção com os branches iss53 e hotfix que você criou. Você fez alguns commits neles e os excluiu diretamente após mesclá-los (merging) no seu branch principal. Esta técnica permite que você mude de contexto (context-switch) de forma rápida e completa — como o seu trabalho é separado em silos onde todas as alterações daquele branch têm a ver com aquele tópico, é mais fácil ver o que aconteceu durante a revisão de código e afins. Você pode manter as alterações lá por minutos, dias ou meses, e mesclá-las (merge) quando estiverem prontas, independentemente da ordem em que foram criadas ou trabalhadas.

Considere um exemplo de fazer algum trabalho (no master), ramificando (branching) para uma issue (iss91), trabalhando nela um pouco, ramificando o segundo branch para tentar outra maneira de lidar com a mesma coisa (iss91v2), voltando ao seu branch master e trabalhando lá por um tempo e, em seguida, ramificando para fazer um trabalho que você não tem certeza se é uma boa ideia (branch dumbidea). O seu histórico de commits ficará parecido com isto:

Agora, digamos que você decida que gosta mais da segunda solução para o seu problema (iss91v2); e você mostrou o branch dumbidea aos seus colegas de trabalho e ele acabou sendo genial. Você pode descartar (throw away) o branch original iss91 (perdendo os commits C5 e C6) e mesclar os outros dois. O seu histórico então fica assim:

Entraremos em mais detalhes sobre os vários fluxos de trabalho possíveis para o seu projeto Git em Git Distribuído, portanto, antes de decidir qual esquema de ramificação (branching scheme) o seu próximo projeto usará, certifique-se de ler esse capítulo.

É importante lembrar ao fazer tudo isso que esses branches são completamente locais. Quando você está ramificando e mesclando (branching e merging), tudo é feito apenas no seu repositório Git — não há comunicação com o servidor.