3.4 Branches no Git - Fluxo de Branches

Como o Git usa uma mesclagem simples de três vias, 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 regularmente alguns deles com outros.

Muitos desenvolvedores Git têm um fluxo de trabalho que adota essa abordagem, como ter apenas código totalmente estável em seu branch master - possivelmente apenas código que foi ou será lançado. Eles têm outro branch paralelo chamado developers ou next, a partir do qual trabalham ou usam para testar a estabilidade - não é necessáriamente sempre estável, mas sempre que chega a um estado estável, pode ser mesclado com o master. É usado para puxar branches de tópico (de curta duração, como seu anterior iss53) quando eles estão prontos, para garantir que eles passem em todos os testes e não introduzam bugs.

Na realidade, estamos falando sobre indicadores que aumentam a linha de commits que você está fazendo. Os branches estáveis ​​estão mais abaixo na linha em seu histórico de commit, e os branches mais avançados estão mais adiante no histórico.

Geralmente é mais fácil pensar neles como silos de trabalho, onde conjuntos de commits passam 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 ramo proposto ou pu (proposed updates) que tem branches integrados que podem não estar prontos para ir para o branch next ou master. A ideia é que seus ramos estejam em vários níveis de estabilidade; quando eles atingem um nível mais estável, eles são mesclados no ramo acima deles. Novamente, não é necessário ter vários branches de longa duração, mas geralmente é útil, especialmente quando você está lidando com projetos muito grandes ou complexos.

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 ou trabalho relacionado. Isso é algo que você provavelmente nunca fez com um VCS antes porque geralmente é muito difícil para 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 deletou diretamente após fundi-los em seu branch principal. Esta técnica permite que você mude de contexto de forma rápida e completa - porque seu trabalho é separado em silos onde todas as mudanças naquele branch têm a ver com aquele tópico, é mais fácil ver o que aconteceu durante a revisão de código. Você pode manter as alterações lá por minutos, dias ou meses e mesclá-las quando estiverem prontas, independentemente da ordem em que foram criadas ou trabalhadas.

Considere um exemplo de como fazer algum trabalho (no master), ramificando para um problema (iss91), trabalhando nisso 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 então ramificando para fazer algum trabalho que você não tem certeza se é uma boa ideia (branch dumbidea). Seu histórico de commits será parecido com isto:

Agora, digamos que você decida que prefere a segunda solução para o seu problema (iss91v2); e você mostrou o branch dumbidea para seus colegas de trabalho, e acabou sendo um gênio. Você pode descartar o branch iss91 original (perdendo commits C5 e C6) e mesclar os outros dois. Seu histórico será assim:

Iremos entrar em mais detalhes sobre os vários fluxos de trabalho possíveis para seu projeto Git em [ch05-distributed-git], portanto, antes de decidir qual esquema de ramificação seu próximo projeto usará, certifique-se de ler esse capítulo.

É importante lembrar quando você estiver fazendo tudo isso que esses branches são completamente locais. Quando você está ramificando e mesclando, tudo está sendo feito apenas em seu repositório Git - nenhuma comunicação com o servidor está acontecendo.