Adotar uma estratégia de branch do Git

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Sistemas de controle de versão distribuída, como o Git, oferecem flexibilidade na forma como você usa o controle de versão para compartilhar e gerenciar código. Sua equipe deve encontrar um equilíbrio entre essa flexibilidade e a necessidade de colaborar e compartilhar código de maneira consistente.

Os membros da equipe publicam, compartilham, revisam e iteram em alterações de código por meio de ramificações do Git compartilhadas com outras pessoas. Adote uma estratégia de ramificação para sua equipe. Você pode colaborar melhor e gastar menos tempo gerenciando o controle de versão e mais tempo desenvolvendo código.

As estratégias de ramificação a seguir se baseiam na maneira como usamos o Git aqui na Microsoft. Para obter mais informações, consulte Como usamos o Git na Microsoft.

Mantenha sua estratégia de ramificação simples

Mantenha sua estratégia de ramificação simples. Crie sua estratégia com base nesses três conceitos:

• Use branches de recursos para todos os novos recursos e correções de bugs.
• Mescle as ramificações de recursos na ramificação principal usando solicitações de pull.
• Mantenha um branch principal atualizado e de alta qualidade.

Uma estratégia que estenda esses conceitos e evite contradições resultará em um fluxo de trabalho de controle de versão consistente e fácil de seguir para sua equipe.

Usar ramificações de recursos para seu trabalho

Desenvolva seus recursos e corrija bugs em ramificações de recursos com base na ramificação principal. Essas ramificações também são conhecidas como branches do tópico. As ramificações de recursos isolam o trabalho em andamento do trabalho concluído na ramificação principal. Os GIT branches são baratos de criar e manter. Mesmo pequenas correções e alterações devem ter seus próprios branches de recurso.

A criação de branches de recursos para todas as alterações simplifica a revisão do histórico. Examine os commits feitos no branch e examine a solicitação de pull que mesclou o branch.

Nomear seus branches de recursos por convenção

Use uma convenção de nomenclatura consistente para seus branches de recursos para identificar o trabalho feito no branch. Você também pode incluir outras informações no nome do branch, como quem criou o branch.

Algumas sugestões para nomear seus branches de recursos:

• users/username/description
• users/username/workitem
• bugfix/description
• feature/feature-name
• feature/feature-area/feature-name
• hotfix/description

Observação

Para obter informações sobre como definir políticas para impor uma estratégia de nomenclatura de branch, consulte Exigir pastas de branch.

Usar sinalizadores de recurso para gerenciar branches de execução prolongada

Saiba mais sobre como usar sinalizadores de recursos em seu código.

Revisar e mesclar o código com PR

A revisão que ocorre em uma PR é fundamental para melhorar a qualidade do código. Mescle apenas branches por meio de PR que passam pelo processo de revisão. Evite mesclar branches à ramificação principal sem uma PR.

As revisões em PR levam tempo para serem concluídas. Sua equipe deve concordar com o que é esperado de criadores e revisores de PR. Distribua as responsabilidades do revisor para compartilhar ideias em sua equipe e distribuir conhecimento da base de código.

Algumas sugestões para PR bem-sucedidas:

• Dois revisores são um número ideal com base na pesquisa.
• Se sua equipe já tiver um processo de revisão de código, traga PR para o que você já está fazendo.
• Tome cuidado ao atribuir os mesmos revisores a um grande número de PR. As PRs funcionam melhor quando as responsabilidades do revisor são compartilhadas em toda a equipe.
• Forneça detalhes suficientes na descrição para atualizar rapidamente os revisores com suas alterações.
• Inclua uma versão de build ou vinculada de suas alterações em execução em um ambiente preparado com sua PR. Outras pessoas podem testar facilmente as alterações.

Manter um branch principal atualizado e de alta qualidade

O código em sua ramificação principal deve passar por testes, compilar de forma limpa e sempre ser atual. Sua ramificação principal precisa dessas qualidades para que os branches de recursos criados por sua equipe comecem a partir de uma boa versão conhecida do código.

Configure uma política de branch para sua ramificação principal que:

• Requer uma PR para mesclar código. Essa abordagem impede pushes diretos para ramificação principal e garante a discussão das alterações propostas.
• Adiciona automaticamente revisores quando uma PR é criada. Os membros da equipe adicionados revisam o código e comentam as alterações na PR.
• Requer um build bem-sucedido para concluir uma PR. O código mesclado na ramificação principal deve ser compilado de forma limpa.

Dica

O pipeline de build para suas PRs deve ser rápido para ser concluído, para que ele não interfira no processo de revisão.

Gerenciar versões

Use branches de versão para coordenar e estabilizar as alterações em uma versão do código. Esse branch é de longa duração e não é mesclado novamente na ramificação principal em uma PR, ao contrário dos branches de recursos. Crie quantos branches de versão forem necessários. Tenha em mente que cada branch de versão ativo representa outra versão do código que você precisa dar suporte. Bloqueie branches de versão quando estiver pronto para parar de dar suporte a uma versão específica.

Usar branches de lançamento

Crie um branch de versão da ramificação principal quando você se aproximar de sua versão ou de outro marco, como o fim de um sprint. Dê a esse branch um nome claro associando-o à versão, por exemplo, versão/20.

Crie branches para corrigir bugs do branch de versão e mesclar novamente no branch de versão em uma PR.

A porta é alterada de volta para a ramificação principal

Certifique-se de que as correções cheguem ao branch de versão e à ramificação principal. Uma abordagem é fazer correções no branch de versão e, em seguida, trazer alterações para a ramificação principal para evitar a regressão em seu código. Outra abordagem (e a empregada pela equipe do Azure DevOps) é sempre fazer alterações na linha principal e, em seguida, portar para o branch de versão. Você pode ler mais sobre nossa estratégia de Fluxo de Versão.

Neste tópico, abordaremos as alterações no branch de versão e a portabilidade delas na linha principal. Use o cherry-picking em vez de mesclar para que você tenha controle exato sobre quais commits são portados de volta para a ramificação principal. Mesclar a ramificação de lançamento na ramificação principal pode gerar alterações específicas de versão que você não deseja na ramificação principal.

Atualize a ramificação principal com uma alteração feita no branch de versão com estas etapas:

1. Crie um novo branch de recurso pela ramificação principal para portar as alterações.
2. Cherry-pick as alterações do branch de versão para o novo branch de recurso.
3. Mescle o branch de recurso novamente na ramificação principal em uma segunda PR.

Esse fluxo de trabalho do branch de versão mantém os pilares do fluxo de trabalho básico intactos: branches de recursos, PR e uma ramificação principal forte que sempre tem a versão mais recente do código.

Por que não usar marcas para versões?

Outros fluxos de trabalho de ramificação usam marcas do Git para marcar um commit específico como uma versão. As marcas são úteis para marcar pontos em seu histórico como importantes. As marcas introduzem etapas extras em seu fluxo de trabalho que não são necessárias se você estiver usando branches para suas versões.

As marcas são mantidas e enviadas por push separadamente de seus commits. Os membros da equipe podem facilmente perder a marcação de um commit e, em seguida, precisam voltar ao histórico depois para corrigir a marca. Você também pode esquecer a etapa extra para efetuar push da marca, deixando o próximo desenvolvedor trabalhando de uma versão mais antiga do código ao dar suporte à versão.

A estratégia do branch de versão estende o fluxo de trabalho de branch de recurso básico para lidar com versões. Sua equipe não precisa adotar nenhum novo processo de controle de versão além das alterações de cherry-pick para porta.

Administrar implantações

Você pode lidar com várias implantações do código da mesma forma que lida com várias versões. Crie uma convenção de nomenclatura clara, como deploy/performance-test, e trate os branches de ambiente como branches de versão. Sua equipe deve concordar com um processo para atualizar branches de implantação com o código da ramificação principal. Correções de bugs de cherry-pick no branch de implantação de volta para a ramificação principal. Use as mesmas etapas que as alterações de portabilidade de um branch de versão.

Uma exceção a essa recomendação é se você estiver usando uma forma de implantação contínua. Use o Azure Pipelines ao trabalhar com a implantação contínua para promover builds da ramificação principal para seus destinos de implantação.