Mesclagem squash e de estratégias

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Ao concluir uma solicitação de pull, você mescla o branch de tópicos em seu branch padrão, geralmente main. Essa mesclagem adiciona as confirmações do branch de tópicos ao branch principal e cria uma confirmação de mesclagem para reconciliar conflitos entre o branch padrão e o tópico. Os comentários e a discussão na solicitação de pull dão mais contexto para as alterações feitas no branch de tópicos.

O histórico de confirmação em seu main branch (ou outro branch padrão) não segue uma linha reta devido ao histórico de branch de tópico relacionado. À medida que um projeto aumenta, o número de branches de tópicos trabalhados ao mesmo tempo aumenta, tornando o histórico de branch padrão cada vez mais difícil de seguir.

O branch padrão é uma representação precisa do histórico de cada branch de tópico, mas é difícil de usar para responder perguntas mais amplas sobre o desenvolvimento do seu projeto.

Pré-requisitos

Mesclagem de squash

A mesclagem de squash é uma opção de mesclagem que permite que você condense o histórico do Git de branches de tópicos ao concluir uma solicitação de pull. Em vez de adicionar cada confirmação no branch de tópico ao histórico do branch padrão, uma mesclagem de squash adiciona todas as alterações de arquivo a uma única nova confirmação no branch padrão. A confirmação de mesclagem de squash não tem uma referência ao branch de tópicos. Ele produz uma nova confirmação que contém todas as alterações do branch de tópico. Recomendamos que você exclua o branch de tópicos para evitar qualquer confusão.

Uma maneira simples de pensar sobre isso é que a mesclagem de squash oferece apenas as alterações de arquivo e uma mesclagem regular fornece as alterações de arquivo e o histórico de confirmação.

Como uma mesclagem de squash é útil?

A mesclagem de squash mantém seus históricos de branch padrão limpos e fáceis de seguir sem exigir alterações de fluxo de trabalho em sua equipe. Os colaboradores do branch de tópicos funcionam como quiserem no branch de tópicos e os branches padrão mantêm um histórico linear usando mesclagens de squash. O histórico de confirmação de um main branch atualizado com mesclagens de squash tem uma confirmação para cada branch mesclado. Você pode percorrer esse histórico para descobrir exatamente quando o trabalho foi feito.

Considerações ao mesclar squash

A mesclagem de squash condensa o histórico de alterações em seu branch padrão, portanto, é importante trabalhar com sua equipe para decidir quando esmagar a mesclagem em vez de manter o histórico de confirmação completo de um branch de tópico. Ao mesclar squash, é uma boa prática excluir o branch de origem. Excluir o branch de origem evita confusão, pois o branch de tópico em si não tem uma confirmação mesclando-a no branch padrão.

Várias bases de mesclagem

A guia Arquivos em uma solicitação de pull detecta diferenças por uma comparação de três lados. O algoritmo leva em conta a última confirmação no branch de destino, a última confirmação no branch de origem e sua base de mesclagem comum, por exemplo, o melhor ancestral comum. O algoritmo é um método rápido, econômico e confiável de detecção de alterações. Infelizmente, em alguns casos, há mais de uma base verdadeira. Na maioria dos repositórios, essa situação é rara, mas em repositórios grandes com muitos usuários ativos, pode ser comum. Você pode verificar manualmente se existem várias bases de mesclagem entre os branches. Para fazer isso, execute git merge-base --all feature master o comando. O Azure DevOps detecta a existência de várias bases de mesclagem para cada PR. Quando eles são detectados, o Azure DevOps exibe a mensagem "Várias bases de mesclagem detectadas. A lista de confirmações exibidas pode estar incompleta" para a PR. Embora o Azure DevOps esteja executando a detecção de várias bases de mesclagem, ele não verifica se a base de mesclagem potencial já foi mesclada ou não. Essa verificação é feita por git merge-base. É por isso que o Azure DevOps pode exibir a mensagem mesmo quando git merge-base relata apenas uma base de mesclagem.

Os cenários de exemplo a seguir são detectados pelo Azure DevOps como várias bases, com as bases de mesclagem indicadas pelos números um e dois:

• Mesclagens cruzadas (também conhecidas como criss-cross) entre ramificações diferentes (relatadas pelo Azure DevOps e git merge-base)

---1---o---A
    \ /
     X
    / \
---2---o---o---B

• Mesclagem de um branch para outros dois (relatado pelo Azure DevOps, mas não por git merge-base isso elimina a base de mesclagem 2)

---1---o---o---o---A
    \         /
     \-------2
      \       \
       \---o---o---o---B

• Lidar com as consequências do branch principal reverte, por exemplo, alterar a confirmação de mesclagem

*   42bb2d2 (HEAD, A) Amended merge commit
|\  
| | *   67c9bb8 (other) Merge branch 'A' into B
| | |\  
| |/ /  
|/| /   
| |/    
| * fa78e32 add second commit
* | 15845c9 add first commit
|/  
* 6a52130 add init

• Reutilização ativa de branches de recursos
• Outras manipulações não intuitivas e complicadas com reversões, escolhas de cereja e mesclagens

A detecção de base de várias mesclagens faz parte da conscientização de segurança. Se houver várias bases de mesclagem, o algoritmo de diferenciação de arquivo para a interface do usuário poderá não detectar corretamente as alterações de arquivo, dependendo da base de mesclagem escolhida. Se os arquivos na solicitação de pull tiverem versões diferentes entre as bases de mesclagem, ocorrerá um aviso base de mesclagem múltipla.

Examine a documentação oficial do git para obter mais detalhes.

Riscos potenciais de segurança de mesclagem de várias bases

• Um usuário mal-intencionado pode abusar do algoritmo de interface do usuário para confirmar alterações mal-intencionadas que não estão presentes na PR.
• Se as alterações propostas na PR já estiverem no branch de destino, elas serão exibidas na guia Arquivos , mas podem não disparar políticas de branch mapeadas para alterações de pasta.
• Dois conjuntos de alterações nos mesmos arquivos de várias bases de mesclagem podem não estar presentes no PR. Esse caso pode criar lacunas lógicas traiçoeiras.

Como resolver o problema de várias bases de mesclagem

Ter várias bases de mesclagem não é necessariamente ruim, mas você deve verificar se está tudo bem. Para se livrar de várias bases de mesclagem, vincule os branches a um único ancestral comum rebasing seu branch no destino ou mesclando o destino em seu branch. Essas ações se livram da mensagem de aviso e ajudam você a verificar se as alterações reais estão bem.

Uma abordagem é redefinir e esconder o progresso antes de reativar ou mesclar. Em seguida, você pode criar um novo branch ou rebasear um vazio e aplicar suas alterações de um ponto claro. Esse processo pode exigir um push forçado para o remoto se suas alterações já estiverem lá.

Como evitar o problema de várias bases de mesclagem

Aqui estão dicas gerais para evitar o problema de base de mesclagem múltipla:

• Ao preparar uma solicitação pull, crie branches de recursos das versões mais recentes do branch principal ou de lançamento.
• Evite criar branches que não se originem diretamente de branches estáveis do repositório, a menos que seja necessário.

O que fazer se o problema de várias bases de mesclagem reaparecer

Em grandes repositórios com muitos colaboradores ativos, esse problema pode ser especialmente inconveniente. Mesmo se você se livrar de várias bases por meio de mesclagem, a situação poderá reaparecer. Se alguém fechar uma solicitação de pull de longa data, isso poderá recriar a situação. Mesmo que as políticas de build e os testes estejam em execução, você não tem meios para concluir a solicitação de pull. Redefinir e iniciar um novo branch pode ajudar. Se nada for alterado, suas alterações provavelmente serão claras, mesmo que a situação se repita.

Próximas etapas

• Resolver conflitos de mesclagem
• Concluir uma solicitação de pull
• Sobre solicitações de pull