Adopt a Git branching strategy (Adotar uma estratégia de ramificação do Git)

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Sistemas de controle de versão distribuídos, como o Git, oferecem flexibilidade em 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 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 são baseadas na maneira como usamos o Git aqui na Microsoft. Para obter mais informações, consulte Como usamos o Git na Microsoft.

Mantenha a sua estratégia de filial simples

Mantenha a sua estratégia de filial simples. Construa a sua estratégia a partir destes três conceitos:

• Use ramificações de recursos para todos os novos recursos e correções de bugs.
• Mescle ramificações de recursos na ramificação principal usando solicitações pull.
• Mantenha uma filial principal atualizada e de alta qualidade.

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

Usar ramificações de recursos para seu trabalho

Desenvolva seus recursos e corrija bugs em ramificações de recursos com base em sua ramificação principal. Esses ramos também são conhecidos como ramos tópicos. As ramificações de recurso isolam o trabalho em andamento do trabalho concluído na ramificação principal. As filiais Git são baratas de criar e manter. Mesmo pequenas correções e alterações devem ter sua própria ramificação de recursos.

A criação de ramificações de recursos para todas as alterações simplifica a revisão do histórico. Observe os commits feitos na ramificação e observe a solicitação pull que mesclou a ramificação.

Nomeie suas ramificações de recursos por convenção

Use uma convenção de nomenclatura consistente para suas ramificações de recursos para identificar o trabalho feito na ramificação. Você também pode incluir outras informações no nome da ramo, como quem criou a ramificação.

Algumas sugestões para nomear suas ramificações de recursos:

• usuários/nome de usuário/descrição
• usuários/nome de usuário/item de trabalho
• correção de bugs/descrição
• nome do recurso/recurso
• característica/área de recurso/nome do recurso
• Hotfix/Descrição

Nota

Para obter informações sobre como definir políticas para impor uma estratégia de nomeação de ramificação, consulte Exigir pastas de filial.

Usar sinalizadores de recursos para gerenciar ramificações de longa duração

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

Revisar e mesclar código com solicitações pull

A revisão que ocorre em uma solicitação pull é fundamental para melhorar a qualidade do código. Mescle ramificações somente por meio de solicitações pull que passam pelo processo de revisão. Evite mesclar ramificações para a ramificação principal sem uma solicitação pull.

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

Algumas sugestões para solicitações pull bem-sucedidas:

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

Mantenha uma filial principal atualizada e de alta qualidade

O código em sua ramificação principal deve passar por testes, construir de forma limpa e estar sempre atualizado. Sua ramificação principal precisa dessas qualidades para que as ramificações de recursos criadas por sua equipe comecem a partir de uma boa versão do código.

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

• Requer uma solicitação pull para mesclar código. Esta abordagem evita empurrões diretos para o ramo principal e garante a discussão das mudanças propostas.
• Adiciona automaticamente revisores quando uma solicitação pull é criada. Os membros da equipe adicionados revisam o código e comentam as alterações na solicitação pull.
• Requer uma compilação bem-sucedida para concluir uma solicitação pull. O código mesclado na ramificação principal deve ser construído de forma limpa.

Gorjeta

O pipeline de compilação para suas solicitações pull deve ser rápido para ser concluído, para que não interfira no processo de revisão.

Gerenciar lançamentos

Use ramificações de liberação para coordenar e estabilizar alterações em uma versão do seu código. Essa ramificação é de longa duração e não é mesclada de volta à ramificação principal em uma solicitação pull, ao contrário das ramificações de recurso. Crie quantas ramificações de liberação você precisar. Lembre-se de que cada ramificação de versão ativa representa outra versão do código que você precisa suportar. Bloqueie ramificações de liberação quando estiver pronto para parar de oferecer suporte a uma versão específica.

Utilizar ramos de lançamento

Crie uma ramificação de liberação a partir da ramificação principal quando se aproximar da sua versão ou de outro marco, como o final de um sprint. Dê a esta ramificação um nome claro associando-a à versão, por exemplo , release/20.

Crie ramificações para corrigir bugs da ramificação de lançamento e mescle-as de volta à ramificação de liberação em uma solicitação pull.

Alterações de porta de volta para a ramificação principal

Certifique-se de que as correções aterrissam tanto na ramificação de liberação quanto na ramificação principal. Uma abordagem é fazer correções na ramificação 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 de DevOps do Azure) é sempre fazer alterações na linha principal e, em seguida, portá-las para a ramificação de versão. Você pode ler mais sobre nossa estratégia de fluxo de liberação.

Neste tópico, abordaremos como fazer alterações na ramificação de lançamento e portá-las para a linha principal. Use cherry-picking em vez de mesclar para que você tenha controle exato sobre quais confirmações são portadas de volta para a ramificação principal. Mesclar a ramificação de liberação na ramificação principal pode trazer alterações específicas de liberação que você não deseja na ramificação principal.

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

1. Crie uma nova ramificação de recurso fora da ramificação principal para portar as alterações.
2. Escolha a dedo as alterações da ramificação de lançamento para a ramificação de novos recursos.
3. Mescle a ramificação de recurso de volta à ramificação principal em uma segunda solicitação pull.

Este fluxo de trabalho de ramificação de versão mantém intactos os pilares do fluxo de trabalho básico: ramificações de recursos, solicitações pull e uma ramificação principal forte que sempre tem a versão mais recente do código.

Por que não usar tags para lançamentos?

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

As tags são mantidas e enviadas separadamente das suas confirmações. Os membros da equipe podem facilmente perder a marcação de uma confirmação e, em seguida, ter que voltar pelo histórico depois para corrigir a tag. Você também pode esquecer a etapa extra para empurrar a tag, deixando o próximo desenvolvedor trabalhando a partir de uma versão mais antiga do código ao suportar a versão.

A estratégia de ramificação de liberação estende o fluxo de trabalho de ramificação 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 porta escolhidas a dedo.

Gerenciar implantações

Você pode lidar com várias implantações do seu 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 as ramificações do ambiente como ramificações de versão. Sua equipe deve concordar com um processo para atualizar as ramificações de implantação com o código da ramificação principal. Correções de bugs seletivas na ramificação de implantação de volta para a ramificação principal. Use as mesmas etapas que a portabilidade de alterações de uma ramificação 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 implantação contínua para promover compilações de sua ramificação principal para seus destinos de implantação.