Quando você usaria as diferentes estratégias de mesclagem do git?

A partir da man page no gitmerge, há várias estratégias de mesclagem que você pode usar.

  • resolve – Isso só pode resolver duas cabeças (ou seja, o ramo atual e outro ramo de onde você tirou) usando o algoritmo de mesclagem de 3 vias. Ele tenta detectar cuidadosamente as ambigüidades cruzadas e é considerado geralmente seguro e rápido.

  • recursivo – Isso só pode resolver duas cabeças usando o algoritmo de mesclagem de 3 vias. Quando há mais de um ancestral comum que pode ser usado para mesclagem de 3 vias, ele cria uma tree mesclada dos ancestrais comuns e usa isso como a tree de referência para a mesclagem de 3 vias. Isso foi relatado para resultar em menos conflitos de mesclagem sem causar mesclagens incorretas por testes feitos em confirmações de mesclagem reais obtidas do histórico de desenvolvimento do kernel do Linux 2.6. Além disso, isso pode detectar e manipular mesclagens envolvendo renomeações. Essa é a estratégia de mesclagem padrão ao puxar ou mesclar uma ramificação.

  • octopus – Isso resolve mais de um caso de duas cabeças, mas se recusa a fazer uma mesclagem complexa que requer resolução manual. Destina-se principalmente a ser usado para agrupar headers de tópicos juntos. Essa é a estratégia de mesclagem padrão ao extrair ou mesclar mais de uma ramificação.

  • ours – Isso resolve qualquer número de cabeças, mas o resultado da mesclagem é sempre o atual header da ramificação. Destina-se a ser usado para replace o antigo histórico de desenvolvimento dos ramos laterais.

  • subtree – esta é uma estratégia recursiva modificada. Ao mesclar as trees A e B, se B corresponder a uma subtree de A, B será ajustado primeiro para corresponder à estrutura em tree de A, em vez de ler as trees no mesmo nível. Esse ajuste também é feito na tree ancestral comum.

Quando devo especificar algo diferente do padrão? Quais cenários são melhores para cada um?

   

Eu não estou familiarizado com a resolução, mas eu usei os outros:

Recursivo

Recursivo é o padrão para mesclagens não adiantadas. Estamos todos familiarizados com isso.

Polvo

Eu usei polvo quando tive várias trees que precisavam ser mescladas. Você vê isso em projetos maiores, onde muitos ramos tiveram desenvolvimento independente e está tudo pronto para se unir em uma única cabeça.

Um ramo de polvo mescla vários headers em um commit, desde que possa fazê-lo de maneira limpa.

Por exemplo, imagine que você tenha um projeto que tenha um mestre e três ramos para mesclar (chame-os de a, b e c).

Uma série de fusões recursivas ficaria assim (observe que a primeira mesclagem foi um avanço rápido, já que não forcei a recursion):

série de fusões recursivas

No entanto, uma mesclagem de polvo único ficaria assim:

commit ae632e99ba0ccd0e9e06d09e8647659220d043b9 Merge: f51262e... c9ce629... aa0f25d... 

fusão de polvo

Nosso

Ours == Eu quero puxar em outra cabeça, mas jogue fora todas as mudanças que a cabeça introduz.

Isso mantém o histórico de um ramo sem nenhum dos efeitos do ramo.

(Leia: Não é nem mesmo olhado as mudanças entre esses ramos. Os branches são apenas mesclados e nada é feito nos arquivos. Se você quiser mesclar no outro branch e toda vez que houver a pergunta “nossa versão do arquivo ou seus versão “você pode usar git merge -X ours )

Subtree

A subtree é útil quando você deseja mesclar outro projeto em um subdiretório do projeto atual. Útil quando você tem uma biblioteca que não deseja include como submódulo.

Na verdade, as duas únicas estratégias que você gostaria de escolher são as nossas se você quiser abandonar as mudanças trazidas pela ramificação, mas manter a ramificação no histórico e subtrair se estiver mesclando projeto independente no subdiretório de superprojeto (como ‘git-gui’ em ‘ repository git ‘).

A mesclagem de octopus é usada automaticamente ao mesclar mais de dois ramos. resolve está aqui principalmente por razões históricas, e para quando você é atingido por casos de canto de estratégia de mesclagem recursiva .

Estratégia de mesclagem “Resolver” x “Recursiva”

Recursiva é a estratégia padrão atual de duas cabeças, mas depois de algumas pesquisas eu finalmente encontrei algumas informações sobre a estratégia de mesclagem “resolver”.

Extraído do livro da O’Reilly, Version Control with Git ( Amazon ) (parafraseado):

Originalmente, “resolver” era a estratégia padrão para as fusões do Git.

Em situações de mesclagem cruzadas, onde há mais de uma base de mesclagem possível, a estratégia de resolução funciona assim: escolha uma das possíveis bases de mesclagem e espere pelo melhor. Isso não é tão ruim quanto parece. Acontece frequentemente que os usuários têm trabalhado em diferentes partes do código. Nesse caso, o Git detecta que está remetendo algumas alterações que já estão em vigor e ignora as alterações duplicadas, evitando o conflito. Ou, se estas são pequenas mudanças que causam conflito, pelo menos o conflito deve ser fácil para o desenvolvedor manipular.

Eu consegui mesclar trees usando “resolver” que falhou com a estratégia recursiva padrão. Eu estava ficando fatal: git write-tree failed to write a tree erro de fatal: git write-tree failed to write a tree , e graças a este post ( espelho ) eu tentei “-s resolve”, o que funcionou. Ainda não sei exatamente por que … mas acho que foi porque eu tinha alterações duplicadas nas duas trees e resolvi “ignorá-las” corretamente.