Mesclagem squash e de estratégias
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
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 fornecem contexto adicional para as alterações feitas no branch de tópicos.
O histórico de commit 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.
Mesclagem 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 cada commit na branch do tópico ser adicionado ao histórico da branch padrão, uma mesclagem de squash adiciona todas as alterações de arquivo a um único novo commit na branch padrão. A confirmação de mesclagem de squash não tem uma referência ao branch de tópico, ela produzirá uma nova commit, que contém todas as alterações do branch de tópico. Além disso, é recomendável excluir 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 por meio do uso de 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 você deve esmagar a mesclagem ou quando deseja 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.
Concluir solicitações de pull com mesclagem de squash
Você pode optar por mesclagem ao concluir uma solicitação de pull no Azure Repos.
Escolha a Squash commit sob o tipo de Mesclagem na caixa de diálogo Solicitação de pull Completa para a mesclagem squash o branch do tópico.
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 (ou seja, 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 as ramificações. Para fazer isso, execute o comando git merge-base --all feature master. 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 o 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 informa apenas uma base de mesclagem.
Observação
Caso você tenha perdido alterações durante uma revisão de relações públicas, certifique-se de que várias bases de mesclagem não sejam a causa raiz.
Os seguintes cenários são detectados pelo Azure DevOps como várias bases (as bases de mesclagem são indicadas pelos números 1 e 2):
- Mesclagens cruzadas (também conhecidas como cruzadas) entre diferentes ramificações (relatadas pelo Azure DevOps e
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Mesclagem de uma ramificação para outras duas (informada pelo Azure DevOps, mas não por
git merge-base. Isso elimina a mesclagem base 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Lidar com consequências de reversões de ramificação principal, 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 pull tiverem versões diferentes entre as bases de mesclagem, ocorrerá um aviso de várias bases de mesclagem.
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.