Estratégias de fusão e fusão de squash
Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019
Ao concluir uma solicitação pull, você mescla a ramificação de tópico em sua ramificação padrão, geralmente main. Essa mesclagem adiciona as confirmações da ramificação de tópico à ramificação principal e cria uma confirmação de mesclagem para reconciliar quaisquer conflitos entre a ramificação padrão e a ramificação de tópico. Os comentários e a discussão na solicitação pull fornecem contexto adicional para as alterações feitas na ramificação do tópico.
O histórico de confirmação em sua main ramificação (ou outra ramificação padrão) não segue uma linha reta, devido ao histórico de ramificação de tópico relacionado. À medida que um projeto cresce, o número de ramificações de tópicos trabalhadas ao mesmo tempo aumenta, tornando o histórico de ramificações padrão cada vez mais difícil de seguir.
A ramificação padrão é uma representação precisa do histórico de cada ramificação de tópico, mas é difícil de usar para responder a perguntas mais amplas sobre o desenvolvimento do seu projeto.
Fusão de squash
A mesclagem de squash é uma opção de mesclagem que permite condensar o histórico do Git de ramificações de tópicos quando você conclui uma solicitação pull. Em vez de cada confirmação na ramificação de tópico ser adicionada ao histórico da ramificação padrão, uma mesclagem de squash adiciona todas as alterações de arquivo a uma única nova confirmação na ramificação padrão. A confirmação de mesclagem do Squash não tem uma referência à ramificação do tópico, ela produzirá uma nova confirmação que contém todas as alterações da ramificação do tópico. Além disso, recomenda-se excluir a ramificação do tópico para evitar qualquer confusão.
Uma maneira simples de pensar sobre isso é que a mesclagem de squash fornece apenas as alterações de arquivo, e uma mesclagem regular fornece as alterações de arquivo e o histórico de confirmação.
Como é que uma fusão de squash é útil?
A fusão de squash mantém seus históricos de filiais padrão limpos e fáceis de seguir sem exigir alterações no fluxo de trabalho de sua equipe. Os colaboradores da ramificação de tópico trabalham como quiserem na ramificação de tópico, e as ramificações padrão mantêm um histórico linear através do uso de mesclagens de squash. O histórico de confirmação de uma main ramificação atualizada com mesclagens de squash tem uma confirmação para cada ramificação mesclada. Você pode percorrer esse histórico para descobrir exatamente quando o trabalho foi feito.
Considerações ao fundir squash
A fusão de squash condensa o histórico de alterações em sua ramificação padrão, por isso é importante trabalhar com sua equipe para decidir quando você deve mesclar squash ou quando deseja manter o histórico completo de confirmação de uma ramificação de tópico. Ao mesclar squash, é uma boa prática excluir a ramificação de origem. A exclusão da ramificação de origem evita confusão, pois a ramificação de tópico em si não tem uma confirmação mesclando-a na ramificação padrão.
Conclua solicitações pull com squash merge
Você pode optar por mesclar squash ao concluir uma solicitação pull no Azure Repos.
Escolha Squash commit em Merge type na caixa de diálogo Complete pull request para squash merge the topic branch.
Várias bases de mesclagem
A guia Arquivos em uma solicitação pull deteta diffs por uma comparação de três lados. O algoritmo leva em conta a última confirmação na ramificação de destino, a última confirmação na ramificação 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 detetar alterações. Infelizmente, em alguns casos, há mais de uma base verdadeira. Na maioria dos repositórios esta situação é rara, mas em grandes repositórios com muitos utilizadores ativos, pode ser comum. Você pode verificar manualmente se existem várias bases de mesclagem entre as ramificações. Para fazer isso, execute git merge-base --all feature master o comando. O Azure DevOps deteta a existência de várias bases de mesclagem para cada RP. Quando eles são detetados, o Azure DevOps exibe a mensagem "Várias bases de mesclagem detetadas. A lista de commits exibidos pode estar incompleta" para o PR. Embora o Azure DevOps esteja executando a deteçã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.
Nota
Caso você tenha perdido alterações durante uma revisão de RP, certifique-se de que várias bases de mesclagem não sejam a causa raiz.
Os cenários a seguir são detetados 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 ramificações diferentes (relatadas pelo Azure DevOps, bem como
git merge-base)
---1---o---A
\ /
X
/ \
---2---o---o---B
- Mesclagem de uma ramificação para outras duas (relatada pelo Azure DevOps, mas não por
git merge-baseisso elimina a base de mesclagem 2)
---1---o---o---o---A
\ /
\-------2
\ \
\---o---o---o---B
- Tratamento de rescaldos de reversões de ramificação principal, por exemplo, alterar o compromisso de fusão
* 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 ramificações de recursos
- Outras manipulações não intuitivas e complicadas com reversões, escolhas seletivas e fusões
A deteção de base de mesclagem múltipla faz parte do reconhecimento de segurança. Se houver várias bases de mesclagem, o algoritmo de comparação de arquivos para a interface do usuário pode não detetar 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 base de mesclagem múltipla.
Por favor, reveja a documentação oficial do git para obter mais detalhes.
Potenciais riscos de segurança decorrentes da fusão a partir de várias bases
- Um usuário mal-intencionado pode abusar do algoritmo da interface do usuário para cometer alterações maliciosas que não estão presentes no PR.
- Se as alterações propostas na RP já estiverem na ramificação de destino, elas serão exibidas na guia Arquivos , mas podem não acionar políticas de ramificação 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 as ramificações a um único ancestral comum rebaseando sua ramificação no alvo ou mesclando o destino em sua ramificação. 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 suavemente e armazenar seu progresso antes de rebasear ou mesclar. Em seguida, você pode criar uma nova ramificação ou rebasear uma vazia e aplicar suas alterações a partir de um ponto claro. Esse processo pode exigir um push de força para remoto se as alterações já estiverem lá.
Como evitar o problema de várias bases de mesclagem
Aqui estão dicas gerais para evitar o problema da base de mesclagem múltipla:
- Ao preparar uma solicitação pull, crie ramificações de recursos a partir das versões mais recentes da ramificação principal ou de versão.
- Evite criar ramificações que não se originam diretamente de ramificações 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 contribuidores ativos, esse problema pode ser especialmente inconveniente. Mesmo que você se livre de várias bases via mesclagem, a situação pode reaparecer. Se alguém fechar um pull request de longa data, isso pode recriar a situação. Mesmo que as políticas de compilação e os testes estejam em execução, você não tem meios de concluir a solicitação pull. Redefinir e iniciar uma nova ramificação pode ajudar. Se nada for alterado, as suas alterações são provavelmente claras, mesmo que a situação se repita.