Adote uma estratégia de ramificação 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 no Microsoft.

Mantenha a sua estratégia de filial simples

Mantenha a sua estratégia de branches 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 um ramo principal de alta qualidade e up-todata.

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.

Utilize branches de funcionalidade para o seu trabalho

Desenvolva as suas funcionalidades e corrija bugs em ramificações de funcionalidades com base na sua ramificação principal. Esses ramos também são conhecidos como ramos tópicos . As branches de funcionalidades isolam o trabalho em progresso 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 a sua própria ramificação de funcionalidade.

A criação de ramificações de funcionalidades para todas as suas 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 as suas ramificações de funcionalidades de acordo com uma 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 do ramo, como quem criou o ramo.

Algumas sugestões para nomear as suas branches de funcionalidades:

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

Observação

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

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

Saiba mais sobre utilizando sinalizadores de recursos no 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. Integre branches somente através de pull requests que tenham passado pelo seu processo de revisão. Evite mesclar ramificações para a ramificação principal sem uma solicitação pull.

As revisões de pull requests 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 pull requests bem-sucedidos:

• Dois revisores é um número ideal com base na pesquisa.
• Se a sua equipa já tiver um processo de revisão de código, incorpore pedidos de pull no que já está a fazer.
• Tenha cuidado ao atribuir os mesmos revisores a um grande número de pull requests. 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 um ramo principal de alta qualidade e atualizado com up-to.

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

Configure uma de política de ramificação para sua ramificação 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 um pull request. O código mesclado na ramificação principal deve ser construído sem erros.

Tip

O pipeline de compilação para os seus pull requests deve ser rápido a concluir, para que não interfira no processo de revisão.

Gerenciar lançamentos

Use branches de release para coordenar e estabilizar alterações em uma release do seu código. Essa ramificação é de longa duração e não é integrada de volta à ramificação principal em um pedido de pull, ao contrário das ramificações de funcionalidade. 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.

Usar ramificações de liberação

Crie um ramo de lançamento a partir do ramo principal quando se aproximar do lançamento 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 sejam aplicadas tanto no ramo de lançamento quanto no ramo principal. Uma abordagem é fazer correções na ramificação de versão e, em seguida, integrar as alterações na ramificação principal para evitar a regressão no 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 a nossa estratégia de "Release Flow" .

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 tenha controle exato sobre quais commits são integrados de volta à 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 funcionalidades de volta à ramificação principal através de um segundo pull request.

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 um commit específico 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 equipa podem facilmente esquecer de etiquetar uma confirmação e depois terão que percorrer o histórico para corrigir a etiqueta. Você também pode esquecer a etapa extra para fazer o push da tag, deixando o próximo desenvolvedor a trabalhar a partir de uma versão mais antiga do código durante o suporte à versão.

A estratégia de ramificação de publicação estende o fluxo de trabalho básico de ramificação de funcionalidades 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 de implantação/teste de desempenho, e trate as ramificações do ambiente como ramificações de versão. A sua equipa deverá concordar em um processo para atualizar os ramos de implementação com o código do ramo principal. Correções de bugs seletivas na ramificação de implantação de volta para a ramificação principal. Siga os mesmos passos que na adaptação de alterações de um ramo de release.

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