Git merge estratégia recursiva nossa

Nos Termos de Lehman.
Os conflitos de fusão não são estranhos para quem usa alguma forma de controle de versão. O Git faz um ótimo trabalho em conflitos de fusão automática, mas há muitos casos em que o Git não pode determinar o que deve ser feito automaticamente e é necessária uma fusão manual. Embora isso possa ser uma dor às vezes, o Git fornece muitas ferramentas úteis para ajudar com fusões mais difíceis. Especificamente, opções como a nossa e a deles permitem que diga a Git que estratégia usar ao manipular conflitos de mesclagem, então não precisamos juntá-los manualmente.
Deixe-nos assumir que temos um ramo, ramo1, que divergiu do nosso ramo principal. Uma vez que branch1 split do ramo principal tanto branch1 como master fizeram alterações na mesma linha do mesmo arquivo. Isso significa que haverá conflitos de mesclagem que a Git não pode resolver para nós.
Resolvendo conflitos no meio de um rebase.
Se estamos tentando rebase nosso ramo com as novas mudanças no master, podemos fazer algo como o seguinte.
Observe a saída do git diff. Pode haver muitos conflitos dentro do arquivo, estou apenas mostrando um por brevidade. Uma vez que este é um rebase, o HEAD é o ramo com o qual estamos rebaixando (mestre). Se eu quiser tirar todas as mudanças para um arquivo do branch1, o ramo atual, eu posso executar o git checkout - seu nome de arquivo, em vez de lidar com ele manualmente. Da mesma forma, se eu quiser aceitar todas as mudanças do mestre, o ramo com o qual estou rebaixando, posso usar o git checkout - o seu nome de arquivo.
É importante notar que o significado do nosso e do seu é revertido do seu significado normal quando usado para um rebase. Isso ocorre porque o reescalonamento remete o ramo atual. Começa um de cada vez em cima do ramo com o qual queremos reescrever. No nosso caso, os compromissos da branch1 estão sendo repetidos no topo do mestre. Isso torna o mestre "base" ramo neste caso, que é o motivo pelo qual o nosso terá as mudanças do mestre em vez do branch1.
Resolver conflitos no meio de uma mesclagem.
Conforme mencionado acima, a semântica nossa e a deles mudam quando são usadas em um rebase. Se estamos tentando resolver conflitos no meio de uma mesclagem, podemos usar o nosso para aceitar as mudanças do ramo em que estamos atualmente e as suas para aceitar mudanças do ramo em que estamos mesclando.
Deixe-nos assumir que estamos tentando realizar uma mesclagem da seguinte maneira.
Desta vez, o HEAD é nosso ramo atual, mestre. Se quisermos aceitar todas as alterações para um arquivo específico de nossa filial atual, podemos usar o git checkout - our filename. Caso contrário, eu posso aceitar todas as mudanças do ramo em que estou mesclando usando git checkout - seu nome de arquivo.
Escolhendo uma estratégia de fusão de antemão.
Você pode ter percebido que resolver conflitos de fusão com os nossos e os deles no meio de uma rebase ou fusão é o mesmo, exceto que a semântica do que o nosso e o deles se refere são diferentes. Ambos usam uma bandeira no git checkout para escolher o que deve ser feito por arquivo. Isso é muito útil se você não planejasse ter conflitos de fusão e eles aparecem no meio de um rebase / merge ou se você quiser usar uma estratégia diferente dependendo do arquivo. Isso significa que para um arquivo você poderia usar o nosso, outro deles, e outro poderia ser feito manualmente.
Nos casos em que você sabe que você sempre deseja resolver conflitos de mesclagem da mesma forma, você pode escolher uma estratégia de mesclagem (como a nossa ou a sua) antes de executar o rebase ou a mesclagem. A estratégia de mesclagem padrão é uma fusão recursiva. Você também pode especificar o algoritmo a ser usado para uma fusão recursiva (paciência, mínimo, histograma ou myers), mas não vamos cobrir aqueles nesta publicação.
Você pode escolher a estratégia de mesclagem com --strategy & lt; strategy-name & gt; opção ou - s & lt; nome-estratégia & gt; abreviado.
Agora você deve poder adicionar as nossas e suas opções ao seu arsenal de resolução de fusão Git. Sempre que você se encontra tomando todas as mudanças de um único ramo, essa deve ser sua fila para usar o nosso ou o deles. E não esqueça que o significado do nosso e deles se altera dentro de um rebase.

estratégia de fusão de Git, nossa recursiva nossa
Obter através da App Store Leia esta publicação em nosso aplicativo!
(Git Fusion) Quando usar o nosso & # 39; estratégia, nossa? opção e & # 39; theirs & # 39; opção?
Definição de estratégia de fusão recursiva tirada da documentação de mesclagem de git.
Isso só pode resolver duas cabeças usando um algoritmo de mesclagem de 3 vias. Quando há mais de um antepassado comum que pode ser usado para a mesclagem de 3 vias, ele cria uma árvore mesclada dos antepassados ​​comuns e usa isso como a árvore de referência para a mesclagem de 3 vias. Isso foi relatado como resultado de menos conflitos de fusão sem causar mismerges por testes feitos em compromissos de fusão reais tirados do histórico de desenvolvimento do kernel do Linux 2.6. Além disso, isso pode detectar e manipular fusões envolvendo renomeações. Esta é a estratégia de mesclagem padrão ao puxar ou mesclar um ramo.
A estratégia recursiva pode levar as seguintes opções:
Conforme afirmado, a estratégia recursiva, que é a estratégia padrão, faz uso do algoritmo de mesclagem recursiva de 3 vias (explicado aqui e na Wikipédia).
A minha compreensão é que os tipos de conflitos devem ser resolvidos manualmente e geralmente são representados assim.
A nossa opção da estratégia de fusão recursiva é documentada da seguinte forma:
Esta opção força os tipos de conflitos a serem resolvidos automaticamente, favorecendo nossa versão. As mudanças da outra árvore que não estão em conflito com o nosso lado são refletidas no resultado de mesclagem. Para um arquivo binário, todo o conteúdo é retirado do nosso lado.
Isso não deve ser confundido com a nossa estratégia de fusão, que nem sequer olha o que a outra árvore contém. Ele descarta tudo o que a outra árvore fez, declarando que nossa história contém tudo o que aconteceu nele.
Agora suponha que eu tenha as cabeças de dois ramos Y e M, com um antepassado básico comum B, como se segue.
Ao combinar Y e M usando a estratégia recursiva padrão, a linha 30 se tornará Print ("hello"); uma vez que na linha 30, Y representa uma mudança do antepassado base e M não. Mas se eu estivesse no ramo M e corria.
git merge - s recursive - X nossa Y.
a linha 30 será impresso ("bye"); na produção combinada?
Para aqueles que dizem que isso é óbvio, note que a nossa opção afirma.
Esta opção força os tipos de conflitos a serem resolvidos automaticamente, favorecendo nossa versão.
Mas (como eu entendo) não existe um conflito na linha 30.
Para completar, também darei a documentação da sua opção:
Este é o oposto do nosso.
A documentação para a nossa estratégia é a seguinte:
Isso resolve qualquer número de cabeças, mas a árvore resultante da mesclagem é sempre a da cabeça atual do ramo, ignorando efetivamente todas as mudanças de todos os outros ramos. É destinado a substituir o antigo histórico de desenvolvimento de filiais laterais. Observe que isso é diferente da opção - Xours para a estratégia de mesclagem recursiva.
Então, voltando ao exemplo acima, se eu correr.
git merge - é nosso Y.
no ramo M, é claro que a linha 30 será Print ("bye"); na produção resultante da fusão. Neste caso, por que também não existe uma estratégia deles? Como posso alcançar um comportamento igual e oposto à nossa estratégia?
Estou perguntando porque estou trabalhando em um projeto onde eu quero substituir de forma regular e completa o ramo mestre com mudanças de outro ramo de desenvolvimento, sempre que o código no ramo de desenvolvimento for compilado com sucesso. Desta forma, posso garantir que o meu ramo de desenvolvimento nunca se afaste muito do ramo principal e também que o código no ramo mestre seja construído com sucesso.
Eu vi essa questão que recomenda a solução.
Mas o Git simplesmente produz já está atualizado, apesar do fato de que os dois ramos possuem código diferente (e dev-branch é, na verdade, alguns cometem à frente do mestre).
Minha solução atual é fazer.
git merge - s recursive - X theirs dev-branch.
Eu também vi essa questão que recomenda usar a opção deles da estratégia recursiva. Mas, como a nossa opção da estratégia recursiva é claramente diferente da nossa estratégia, também a opção da sua estratégia recursiva seria diferente da estratégia deles de que estou falando.
git merge - s recursive - X nossa Y irá linha 30 tornar-se Print ("bye"); na produção combinada?
Não, também produzirá Print ("hello"); . Isso ocorre porque apenas o outro lado (ramo Y) mudou esse arquivo, a versão do arquivo no ramo M é o mesmo do antepassado B, então a estratégia de mesclagem recursiva mantém a versão atualizada do ramo Y.
E você pode tentar: somente a versão do arquivo do ramo M é diferente de seu antepassado B (como commit para alterar 30 linhas como Print ("bye1")), então as opções - X podem funcionar. Agora, se você usar o git merge - s recursive - X nossa Y, a saída será Print ("bye1"); .
E você também pode encontrar na Figura 4 do artigo que você ligou, se um lado do arquivo for o mesmo que seu antepassado (como linha 30 e 70), o arquivo manterá a versão do outro lado (alterada) como a mesclagem resulta.
Razão para git merge - s nossa saída Y Print ("bye") ;:
Como diz o documento, isso resolve qualquer número de cabeças, mas a árvore resultante da mesclagem é sempre a da atual cabeça de derivação, ignorando efetivamente todas as mudanças de todos os outros ramos.
Isso significa que ele ignorará a versão do ramo Y e apenas manterá a versão como ramo atual. Então você obteve o resultado como a versão do M Branch Print ("bye"); .
Por que não existe uma combinação de git - é a deles para a opção - s:
Git definiu apenas as estratégias de mesclagem com o octupus, o nosso, o recursivo, a resolução e a subárvore, de modo que o deles não pode ser reconhecido e é um problema de design. Pelo motivo detalhado, apenas os desenvolvedores de sistemas de controle de versão git podem saber.
Para sua situação (certifique-se de que o ramo de desenvolvimento sobrescreva o ramo principal), você pode escolher o último commit do ramo de desenvolvimento para o ramo principal com a opção - X deles:
Isso substituirá completamente o ramo principal.
Nota: o desenvolvimento no comando git cherry-pick significa o compromisso com o qual o ramo de desenvolvimento é apontar (o último commit no ramo de desenvolvimento). Você também pode usar o valor commit sha-1.

estratégia de fusão de Git, nossa recursiva nossa
Obter através da App Store Leia esta publicação em nosso aplicativo!
Como seleciono uma estratégia de mesclagem para um rebase git?
git-rebase man page mentions - X & lt; option & gt; pode ser passado para git-merge. Quando / como exatamente?
Gostaria de reescrever aplicando patches com estratégia recursiva e sua opção (aplique o que quer que seja, em vez de ignorar todos os compromissos conflitantes). Eu não quero fundir, eu quero tornar o histórico linear.
mas git rejeita - X em ambos os casos.
git rebase - Os trabalhos em versões recentes, exceto os conflitos de árvore, precisam ser resolvidos manualmente. Você precisa executar git rebase - X seus --continuar (com - X repetido) depois de resolver esses conflitos.
Você pode usar isso com o Git v1.7.3 ou versões posteriores.
Das Notas de versão do Git v1.7.3:
git rebase --strategy & lt; s & gt; Aprendeu a opção - X para passar opções extras que são entendidas pela estratégia de mesclagem escolhida.
NB: "O nosso" e "deles" significam o oposto do que fazem durante uma fusão direta. Em outras palavras, "deles" favorece os compromissos no ramo atual.
Atualização: Editado para ser mais claro.
Isto é para estratégias de fusão que vêm com seu próprio conjunto de opções.
deve funcionar, embora este patch mencione (fevereiro de 2010):
A página de manuais diz que o git-rebase suporta estratégias de mesclagem, mas o comando rebase não sabe sobre - X, e dá o uso quando apresentado.
Então, se ainda não funciona, está sendo debatido agora mesmo!
(apoiado em git recente)
Não ignore as opções de mesclagem no rebase interativo.
A estratégia de mesclagem e suas opções podem ser especificadas em git rebase, mas com - interativo, elas foram completamente ignoradas.
Assinatura: Arnaud Fontaine.
Isso significa que - X e estratégia agora funcionam com rebase interativo, bem como rebase simples.
Como disse o iCrazy, esse recurso só está disponível para o git 1.7.3 em diante. Então, para as almas pobres (como eu) ainda usando 1.7.1, eu apresento uma solução que eu fiz:
É um script muito bem polido (e, portanto, longo), destinado a uso de produção: opções de ui, manipula vários arquivos, verifique se o arquivo realmente possui marcadores de conflito, etc., mas o "núcleo" pode ser resumido em 2 linhas:

estratégia de fusão de Git, nossa recursiva nossa
Obter através da App Store Leia esta publicação em nosso aplicativo!
Escolha a estratégia de mesclagem Git para arquivos específicos ("nossa", "quão mina", "eles" e "quê?"
Eu estou no meio do rebasing depois de um git pull --rebase. Eu tenho alguns arquivos que têm conflitos de mesclagem. Como posso aceitar "suas" mudanças ou "minhas" mudanças para arquivos específicos?
Normalmente, eu apenas abri o arquivo ou uma ferramenta de mesclagem e aceito manualmente todas as "suas" ou "minhas" mudanças. No entanto, eu suspeito que estou faltando um comando git conveniente.
Além disso, note que só poderei escolher uma estratégia de mesclagem para cada arquivo quando eu vejo quais arquivos atingem conflitos e possivelmente quais são os conflitos.
Para cada arquivo em conflito que você obtém, você pode especificar.
Ao verificar os caminhos do índice, verifique o estágio # 2 (nosso) ou o # 3 (deles) para caminhos não misturados.
O índice pode conter entradas não associadas devido a uma fusão falhada anterior. Por padrão, se você tentar verificar essa entrada do índice, a operação de saída falhará e nada será verificado. Usando - f irá ignorar essas entradas não combinadas. O conteúdo de um lado específico da mesclagem pode ser verificado fora do índice, usando - our ou - theirs. Com - m, as alterações feitas no arquivo da árvore de trabalho podem ser descartadas para recriar o resultado de mesclagem conflitante original.
Mesmo que esta questão seja respondida, fornecendo um exemplo sobre o que "eles" e "nosso" significa no caso de git rebase vs misge. Veja este link.
o deles é realmente o ramo atual no caso de rebase. Portanto, o conjunto de comandos abaixo está realmente aceitando as mudanças de ramo atuais sobre o ramo remoto.
Para fundir o significado deles e o nosso é revertido. Então, para obter o mesmo efeito durante uma mesclagem, mantenha suas mudanças de ramo atuais sobre o ramo remoto sendo mesclado.
Tenha em atenção que git checkout --ours | --sus substituirão completamente os arquivos, escolhendo o deles ou a nossa, o que pode ser ou não o que deseja fazer (se você tiver alguma alteração não conflitante proveniente do outro lado, eles serão perdidos).
Se, em vez disso, você deseja executar uma fusão de três vias no arquivo, e apenas resolver os tipos de conflitos usando --ours | --theirs, enquanto mantêm manchas não conflitantes dos dois lados no lugar, você pode querer recorrer à fusão de git - Arquivo ; veja detalhes nesta resposta.