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 dão mais contexto para as alterações feitas na ramificação do tópico.

O histórico de commits de na sua ramificação main (ou outra ramificação padrão) não segue uma linha reta, devido ao histórico da ramificação de tópicos relacionados. À 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.

Pré-requisitos

Categoria	Requerimentos
Acesso ao projeto	Membro de um projeto .
Permissões	- Ver código em projetos privados: Acesso pelo menos Básico. - Clone ou contribua para o código em projetos privados: Membro do grupo de segurança Contributors ou permissões correspondentes no projeto. - Definir permissões de ramo ou repositório: Configurar permissões para o ramo ou repositório. - Alterar ramificação padrão: Editar políticas e permissões para o repositório. - Importar um repositório: Membro do grupo de segurança Administradores de Projeto ou permissão de nível de projeto Git Criar repositório definida como Permitir. Para obter mais informações, consulte Definir permissões do repositório Git.
Serviços	Repos ativado.
Ferramentas	Opcional. Utilize os comandos az repos: Azure DevOps CLI.

Observação

Em projetos públicos, os usuários com acesso Partes Interessadas têm acesso total aos repositórios do Azure, incluindo visualização, clonagem e contribuição para o código.

Fusão de squash

A integração de squash é uma opção de integração que permite condensar o histórico do Git de ramificações de assunto quando se conclui uma solicitação pull. Em vez de adicionar cada confirmação na ramificação de tópico 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 de squash não tem uma referência à ramificação do tópico. Ele produz um novo de confirmação que contém todas as alterações da ramificação do tópico. Recomendamos que você exclua a ramificação do tópico para evitar qualquer confusão.

Uma maneira simples de encarar isto é que a mesclagem squash fornece apenas as alterações de arquivo, enquanto uma mesclagem regular fornece as alterações de arquivo e o histórico de commits.

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 usando mesclagens de squash. O histórico de commits de uma ramificação main atualizada com squash merges tem um commit para cada ramificação mesclada. Você pode percorrer esse histórico para descobrir exatamente quando o trabalho foi feito.

Considerações ao fazer squash merge

A squash merge condensa o histórico de alterações na sua ramificação padrão, por isso é importante trabalhar com a sua equipa para decidir quando realizar um squash merge em vez de manter o histórico completo de commits 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, uma vez que o ramo de tópico em si não possui um commit que o una ao ramo padrão.

Conclua solicitações de pull com squash merge

Você pode optar por mesclar squash ao concluir uma solicitação pull no Azure Repos.

Escolha a confirmação de Squash no tipo de mesclagem na caixa de diálogo Concluir solicitação pull para mesclar a ramificação do tópico.

Várias bases de mesclagem

A aba Arquivos num pull request deteta diferenças através de uma comparação de três lados. O algoritmo leva em conta o último commit na ramificação de destino, o último commit na ramificação de origem e a sua base de mesclagem comum , por exemplo, 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 o comando git merge-base --all feature master. 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.

Observação

Caso tenhas perdido alterações durante uma revisão de PR, certifica-te de que várias bases de mesclagem não sejam a causa raiz.

Os cenários de exemplo a seguir são detetados 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 cruzadas) entre ramificações diferentes (relatadas pelo Azure DevOps e git merge-base)

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

• Mesclagem de uma ramificação em outras duas (reportado pelo Azure DevOps, mas não por git merge-base, que remove a base de mesclagem 2)

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

• Lidar com o processo de reversões no ramo principal, por exemplo, alterar o commit 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 funcionalidades
• Outras manipulações não intuitivas e complicadas com reversões, escolhas seletivas e fusões

A deteção de base de fusão múltipla faz parte da sensibilização para a 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.

Consulte 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 no PR 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 é fazer um reset suave e guardar o seu progresso antes de rebasear ou fazer merge. Em seguida, podes criar um novo ramo ou fazer rebase num ramo vazio e aplicar as tuas alterações a partir de um ponto de partida 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 um pull request, crie branches de funcionalidades a partir das versões mais recentes da ramificação principal ou de lançamento.
• 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 se livre de várias bases via fusão, 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.

Próximos passos

• Resolver conflitos de mesclagem
• Conclua uma solicitação pull
• Acerca dos pull requests