Adotar uma estratégia de ramificação do Git

Azure DevOps Services | Servidor Azure DevOps | Azure DevOps Server 2022 | Azure DevOps Server 2020

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 branches do Git compartilhados 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 branch simples

Mantenha sua estratégia de branch 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.
• Mesclar branches de recursos no branch principal usando solicitações de pull.
• Mantenha uma ramificação principal de alta qualidade up-todata.

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

Usar branches de recursos para seu trabalho

Desenvolva seus recursos e corrija bugs em branches de recursos com base em seu branch principal. Esses branches também são conhecidos como branches de tópico. Os branches de recursos isolam o trabalho em andamento do trabalho concluído no branch principal. As ramificações do Git são baratas para criar e manter. Mesmo pequenas correções e alterações devem ter seu próprio branch de recursos.

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

Nomeie 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/descrição
• feature/feature-name
• feature/feature-area/feature-name
• hotfix/descrição

Usar sinalizadores de recursos para gerenciar branches de execução longa

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

Examinar e mesclar código com solicitações de pull

A revisão que ocorre em uma solicitação de pull é essencial para melhorar a qualidade do código. Apenas mesclar branches por meio de solicitações de pull que passam pelo processo de revisão. Evite mesclar branches ao branch principal sem uma solicitação de pull.

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

Algumas sugestões para solicitações de pull 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 solicitações de pull para o que você já está fazendo.
• Tome cuidado ao atribuir os mesmos revisores a um grande número de solicitações de pull. As solicitações de pull 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 um build ou uma versão vinculada de suas alterações em execução em um ambiente preparado com sua solicitação de pull. Outras pessoas podem testar facilmente as alterações.

Manter uma ramificação principal de alta qualidade up-todata

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

Configure uma política de branch para o branch principal que:

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

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 de volta ao branch principal em uma solicitação de pull, ao contrário dos branches de recursos. Crie quantas ramificações de lançamento forem necessárias. 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 versão

Crie um branch de lançamento do branch 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 lançamento e mesclar novamente no branch de lançamento em uma solicitação de pull.

Alterações de porta de volta para o branch principal

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

Neste tópico, abordaremos fazer alterações no branch de lançamento e portar-las na linha principal. Use a seleção de cereja em vez de mesclar para que você tenha controle exato sobre quais confirmações são portadas de volta para o branch principal. A mesclagem do branch de lançamento no branch principal pode trazer alterações específicas à versão que você não deseja no branch principal.

Atualize o branch principal com uma alteração feita no branch de lançamento com estas etapas:

1. Crie uma ramificação de recurso fora do branch principal para portar as alterações.
2. Escolha as alterações do branch de lançamento para o novo branch de recursos.
3. Mesclar o branch de recursos de volta ao branch principal em uma segunda solicitação de pull.

Esse fluxo de trabalho do branch de versão mantém os pilares do fluxo de trabalho básico intactos: ramificações de recursos, solicitações de pull e um branch 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 Git para marcar uma confirmação específica 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 suas confirmações. Os membros da equipe podem facilmente perder a marcação de uma confirmação e, em seguida, ter que 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 em uma versão mais antiga do código ao dar suporte à versão.

A estratégia de branch de lançamento estende o fluxo de trabalho básico do branch de recursos para lidar com versões. Sua equipe não precisa adotar nenhum novo processo de controle de versão que não seja a escolha da cereja das alterações de 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 implantar/testar desempenho, 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 do branch principal. Correções de bug de escolha de cereja no branch de implantação de volta para o branch principal. Use as mesmas etapas que as alterações de portabilidade de um branch de lançamento.

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 implantação contínua para promover builds do branch principal para seus destinos de implantação.