Estratégia de fusão Git recursiva

O mecanismo de mesclagem (git misge e git pull commands) permite que as "estratégias de mesclagem" do backend sejam escolhidas com a opção - s. Algumas estratégias também podem tomar suas próprias opções, que podem ser aprovadas ao dar - X & lt; option & gt; argumentos para combinar e / ou git pull.
Isso só pode resolver duas cabeças (ou seja, o ramo atual e outro ramo que você retirou) usando um algoritmo de mesclagem de 3 vias. Ele tenta detectar cuidadosamente as ambiguidades de mesclagem cruzada e é considerado geralmente seguro e rápido.
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 ter as seguintes opções:
Esta opção força os tipos de conflitos a serem automaticamente resolvidos, favorecendo a "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 estratégia de "nossa", 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.
Este é o oposto do "nosso"; note que, ao contrário do "nosso", não há "deles" mescla a estratégia para confundir esta opção de fusão.
Com esta opção, "merge-recursive" gasta um pouco de tempo extra para evitar mismerges que às vezes ocorrem devido a linhas de correspondência sem importância (por exemplo, chaves de funções distintas). Use isso quando os ramos a serem fundidos divergiram de forma selvagem. Veja também git-diff [1] - paciência.
Diz a "fusão-recursiva" para usar um algoritmo de diferença diferente, o que pode ajudar a evitar mismerges que ocorrem devido a linhas de correspondência sem importância (como aparelhos de diferentes funções). Veja também git-diff [1] --diff-algorithm.
ignore-space-change ignore-all-space ignore-space-at-eol.
Trata as linhas com o tipo de mudança de espaço indicado como inalterada por causa de uma fusão de três vias. As mudanças de espaço em branco misturadas com outras alterações em uma linha não são ignoradas. Veja também git-diff [1] - b, - w e --ignore-space-at-eol.
Se a "sua" versão apenas introduzir mudanças de espaço em branco para uma linha, a "nossa" versão é usada;
Se a nossa versão introduzir mudanças no espaço em branco, a versão '' deles '' inclui uma alteração substancial, a 'sua' versão é usada;
Caso contrário, a fusão prossegue da maneira usual.
Isso executa um check-out virtual e check-in de todos os três estágios de um arquivo ao resolver uma mesclagem de três vias. Esta opção destina-se a ser usada quando mesclar ramos com diferentes filtros limpos ou regras de normalização de fim de linha. Consulte "Mesclando ramos com diferentes atributos check-in / checkout" em gitattributes [5] para detalhes.
Desativa a opção renormalize. Isso substitui a variável de configuração fusionar.
Desative a detecção de renomeação. Veja também git-diff [1] --no-renomeação.
Ativar a detecção de renomeação, opcionalmente, definir o limite de similaridade. Este é o padrão. Veja também git-diff [1] --find-renames.
Sinônimo desaprovado para find-renames = & lt; n & gt; .
Esta opção é uma forma mais avançada de estratégia "subárvore", onde a estratégia adivinha a forma como duas árvores devem ser deslocadas para combinar uma com a outra quando se fundem. Em vez disso, o caminho especificado é prefixado (ou despojado desde o início) para tornar a forma de duas árvores coincidir.
Isso resolve casos com mais de duas cabeças, mas se recusa a fazer uma fusão complexa que precisa de resolução manual. É principalmente destinado a ser usado para agrupar as cabeças de tópicos. Essa é a estratégia de mesclagem padrão ao puxar ou juntar mais de uma ramificação.
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 intercalação "recursiva".
Esta é uma estratégia recursiva modificada. Ao mesclar as árvores A e B, se B corresponde a uma subárvore de A, B é primeiro ajustado para coincidir com a estrutura em árvore de A, em vez de ler as árvores no mesmo nível. Este ajuste também é feito para a árvore-antepassada comum.
Com as estratégias que utilizam a fusão de 3 vias (incluindo o padrão, 'recursivo'), se uma alteração for feita em ambos os ramos, mas mais tarde será revertida em um dos ramos, essa mudança estará presente no resultado mesclado; Algumas pessoas acham esse comportamento confuso. Ocorre porque apenas as cabeças e a base de mesclagem são consideradas ao realizar uma mesclagem, e não o indivíduo comete. O algoritmo de mesclagem considera, portanto, a alteração revertida como nenhuma alteração, e substitui a versão alterada.

estratégia de fusão Git recursiva
git-merge - Junte-se a duas ou mais histórias de desenvolvimento.
DESCRIÇÃO.
Incorpora as mudanças dos compromissos nomeados (desde o tempo em que suas histórias divergiram do ramo atual) no ramo atual. Este comando é usado pelo git pull para incorporar mudanças de outro repositório e pode ser usado manualmente para mesclar as mudanças de um ramo para outro.
Suponha que o seguinte histórico exista e o ramo atual seja "mestre":
Então, "git merge topic" irá reproduzir as mudanças feitas no tópico, uma vez que divergiu do mestre (ou seja, E) até a confirmação atual (C) no topo do mestre e gravar o resultado em um novo commit junto com os nomes de os dois controladores de pai e uma mensagem de log do usuário que descreve as alterações.
A segunda sintaxe ("git merge --abort") só pode ser executada após a fusão resultou em conflitos. git merge --abort interromperá o processo de mesclagem e tentará reconstruir o estado de pré-mesclagem. No entanto, se houve alterações não confirmadas quando a mesclagem foi iniciada (e especialmente se essas alterações foram modificadas após a fusão ter sido iniciada), git merge - infelizmente, em alguns casos, não será possível reconstruir as alterações originais (pré-mesclagem). Assim sendo:
Aviso: executar desencadear git com mudanças não-triviais não comprometidas é desencorajado: se possível, pode deixá-lo em um estado que é difícil de recuar no caso de um conflito.
A quarta sintaxe ("git merge --continue") só pode ser executada depois que a mesclagem resultou em conflitos.
Execute a mesclagem e cometer o resultado. Esta opção pode ser usada para substituir --no-commit.
Com --no-commit, execute a mesclagem, mas fingir que a fusão falhou e não autenticar, para dar ao usuário a chance de inspecionar e ajustar mais o resultado de mesclagem antes de cometer.
Invoque um editor antes de comprometer a fusão mecânica bem-sucedida para editar ainda mais a mensagem de mesclagem gerada automaticamente, para que o usuário possa explicar e justificar a mesclagem. A opção --no-edit pode ser usada para aceitar a mensagem gerada automaticamente (isso geralmente é desencorajado). A opção --edit (ou - e) ainda é útil se você estiver dando uma mensagem de rascunho com a opção - m da linha de comando e quiser editá-la no editor.
Os scripts mais antigos podem depender do comportamento histórico de não permitir que o usuário edite a mensagem de registro de mesclagem. Eles verão um editor aberto quando executarem a junção git. Para facilitar a adaptação desses scripts ao comportamento atualizado, a variável de ambiente GIT_MERGE_AUTOEDIT pode ser definida como não no início delas.
Quando a mesclagem é resolvida como uma avanço rápido, atualize apenas o ponteiro do ramo, sem criar um commit de mesclagem. Este é o comportamento padrão.
Crie uma confusão de mesclagem mesmo quando a mesclagem se resolve como um avanço rápido. Este é o comportamento padrão ao combinar uma tag anotada (e possivelmente assinada).
Recuse-se a mesclar e sair com um status diferente de zero, a menos que o HEAD atual já esteja atualizado ou a mesclagem pode ser resolvida como um avanço rápido.
GPG-assinar o compromisso de mesclagem resultante. O argumento keyid é opcional e padrão para a identidade do comitente; se especificado, ele deve estar preso à opção sem espaço.
Além dos nomes das filiais, preencha a mensagem de log com descrições de uma linha de no máximo & lt; n & gt; Compromissos reais que estão sendo mesclados. Veja também git-fmt-merge-msg [1].
Com --no-log não lista descrições de uma linha dos compromissos reais que estão sendo mesclados.
Mostre um diffstat no final da mesclagem. O diffstat também é controlado pela opção de configuração merge. stat.
Com - n ou --no-stat não mostre um diffstat no final da mesclagem.
Produza a árvore de trabalho e o estado do índice como se uma fusão real acontecesse (exceto para a informação de mesclagem), mas na verdade não faça uma confirmação, mova a CABEÇA ou registre $ GIT_DIR / MERGE_HEAD (para causar o próximo comando de confirmação de git para criar um mesclar comprometer). Isso permite que você crie um único commit no topo do ramo atual, cujo efeito é o mesmo que mesclar outro ramo (ou mais no caso de um polvo).
Com --no-squash, execute a mesclagem e comente o resultado. Esta opção pode ser usada para substituir --squash.
Use a estratégia de mesclagem fornecida; podem ser fornecidos mais de uma vez para especificá-los na ordem em que devem ser testados. Se não houver nenhuma opção - s, uma lista integrada de estratégias é usada em vez disso (git merge-recursive ao mesclar uma única cabeça, git merge-octopus caso contrário).
-X & lt; option & gt; --strategy-option = & lt; opção & gt;
Passe a opção de estratégia de mesclagem específica até a estratégia de mesclagem.
Verifique se o compromisso da ponta do ramo lateral sendo mesclado é assinado com uma chave válida, ou seja, uma chave que possui um uid válido: no modelo de confiança padrão, isso significa que a chave de assinatura foi assinada por uma chave confiável. Se a confirmação da ponta do ramo lateral não for assinada com uma chave válida, a fusão será interrompida.
Sinônimos para - marcar e - não estar estatístico; Estes são obsoletos e serão removidos no futuro.
Operar silenciosamente. Implica - não há progresso.
Ativar / desativar o progresso explicitamente. Se nenhum dos dois for especificado, o progresso é mostrado se o erro padrão estiver conectado a um terminal. Observe que nem todas as estratégias de mesclagem podem suportar relatórios de progresso.
Por padrão, o comando git misge se recusa a mesclar histórias que não compartilham um antepassado comum. Esta opção pode ser utilizada para substituir esta segurança ao combinar histórias de dois projetos que iniciaram suas vidas de forma independente. Como esta é uma ocasião muito rara, nenhuma variável de configuração para habilitar isso, por padrão, existe e não será adicionada.
Adicione a assinatura por linha pelo comutador no final da mensagem de log de confirmação. O significado de uma assinatura depende do projeto, mas geralmente certifica que o comitê tem o direito de enviar este trabalho sob a mesma licença e concorda com um Certificado de Origem do Desenvolvedor (veja developercertificate. org/ para obter mais informações).
Defina a mensagem de confirmação a ser usada para a confirmação de mesclagem (no caso de uma delas ser criada).
Se --log for especificado, um shortlog dos compromissos que estão sendo mesclados será anexado à mensagem especificada.
O comando git fmt-merge-msg pode ser usado para dar um bom padrão para invocações automatizadas de mesclagem de git. A mensagem automatizada pode incluir a descrição do ramo.
Permita que o mecanismo rerere atualize o índice com o resultado da resolução de conflito automático, se possível.
Aborte o processo atual de resolução de conflitos e tente reconstruir o estado de pré-mesclagem.
Se houvesse mudanças de trabalho não comprometidas presentes quando a mesclagem começasse, git merge - infeliz, em alguns casos, não conseguirá reconstruir essas alterações. Portanto, é recomendável sempre comprometer ou armazenar as alterações antes de executar a fusão.
git merge --abort é equivalente a git reset - imergem quando MERGE_HEAD está presente.
Depois que uma fusão git parar devido a conflitos, você pode concluir a fusão executando git merge --continue (consulte a seção "COMO RESOLVER CONFLITOS" abaixo).
Compromete, geralmente outras cabeças de filial, a fundir-se em nosso ramo. Especificar mais de um commit criará uma mesclagem com mais de dois pais (chamada carinhosamente chamada de Octopus Merge).
Se nenhum commit for fornecido a partir da linha de comando, mescla os ramos de rastreamento remoto que o ramo atual está configurado para usar como a montante. Veja também a seção de configuração desta página do manual.
Quando FETCH_HEAD (e nenhum outro commit) é especificado, os ramos registrados no arquivo. git / FETCH_HEAD pela invocação anterior da git fetch for fusioning são mesclados para o ramo atual.
CHECKS PRÉ-MERGE.
Antes de aplicar mudanças externas, você deve obter seu próprio trabalho em boa forma e comprometido localmente, portanto, não será bloqueado se houver conflitos. Veja também git-stash [1]. git pull e git merge pararão sem fazer nada quando mudanças locais não comprometidas se sobrepõem com os arquivos que git pull / git merge pode precisar atualizar.
Para evitar a gravação de alterações não relacionadas no commit de mesclagem, git pull e git merge também abortar se houver alterações registradas no índice relativo ao commit HEAD. (Uma exceção é quando as entradas de índice alteradas estão no estado que resultaria da fusão já.)
Se todos os compromissos com nome já são ancestrais de HEAD, a fusão git irá sair com antecedência com a mensagem "Já está atualizada".
MERGE FAST-FORWARD.
Muitas vezes, o chefe de ramo atual é um antepassado do commit nomeado. Este é o caso mais comum especialmente quando invocado a partir de git pull: você está rastreando um repositório upstream, você não cometeu alterações locais e agora deseja atualizar para uma revisão upstream mais recente. Nesse caso, um novo commit não é necessário para armazenar o histórico combinado; Em vez disso, o HEAD (juntamente com o índice) é atualizado para apontar o commit nomeado, sem criar um commit adicional de mesclagem.
Esse comportamento pode ser suprimido com a opção --no-ff.
MERGE VERDADEIRO.
Exceto em uma fusão de avanço rápido (veja acima), os ramos a serem mesclados devem ser vinculados por um compromisso de mesclagem que tem ambos como seus pais.
Uma versão combinada que concilie as mudanças de todos os ramos a serem mesclados é comprometida e sua HEAD, índice e árvore de trabalho são atualizadas para isso. É possível ter modificações na árvore de trabalho, desde que não se sobreponham; A atualização os preservará.
Quando não é óbvio como conciliar as mudanças, acontece o seguinte:
O ponteiro HEAD permanece o mesmo.
O MERGE_HEAD ref está configurado para apontar para o outro cabeçalho.
Os caminhos que se fundiram de forma limpa são atualizados no arquivo de índice e na sua árvore de trabalho.
Para caminhos conflitantes, o arquivo de índice grava até três versões: o estágio 1 armazena a versão do antepassado comum, o estágio 2 da HEAD e o estágio 3 do MERGE_HEAD (você pode inspecionar os estágios com git ls-files - u). Os arquivos da árvore de trabalho contêm o resultado do programa "mesclagem"; ou seja, resultados de fusão de 3 vias com marcadores de conflito familiares e lt; & lt; & lt; === & gt; & gt; & gt; .
Nenhuma outra alteração é feita. Em particular, as modificações locais que você teve antes de iniciar a mesclagem permanecerão iguais e as entradas de índice para elas permanecerão como estavam, ou seja, CHAVE correspondente.
Se você tentou uma fusão que resultou em conflitos complexos e deseja começar de novo, você pode recuperar com git merge - abortar.
TAG DE FUMAÇÃO.
Ao combinar uma marca anotada (e possivelmente assinada), o Git sempre cria um commit de mesclagem, mesmo que seja possível uma mesclagem de avanço rápido e o modelo de mensagem de confirmação seja preparado com a mensagem de tag. Além disso, se a etiqueta for assinada, a verificação de assinatura é relatada como um comentário no modelo de mensagem. Veja também git-tag [1].
Quando você quiser apenas se integrar com o trabalho que conduz ao commit que passa a ser marcado, e. sincronizando com um ponto de lançamento a montante, talvez você não queira fazer um compromisso de mesclagem desnecessário.
Nesse caso, você pode "desempacotar" a etiqueta antes de alimentá-la para juntar-se, ou passar - ff somente quando você não tiver nenhum trabalho por conta própria. por exemplo.
COMO OS CONFLITOS SÃO APRESENTADOS.
Durante uma mesclagem, os arquivos da árvore de trabalho são atualizados para refletir o resultado da mesclagem. Entre as mudanças feitas na versão do antepassado comum, as que não se sobrepõem (ou seja, você mudou uma área do arquivo, enquanto o outro lado deixou essa área intacta, ou vice-versa) são incorporados no resultado final, literalmente. Quando ambos os lados fizeram mudanças na mesma área, no entanto, o Git não pode escolher aleatoriamente um lado sobre o outro e pede que você o resolva deixando o que ambos os lados fizeram nessa área.
Por padrão, o Git usa o mesmo estilo que o usado pelo programa de "mesclagem" do conjunto RCS para apresentar um bink tão conflitante, como este:
A área onde um par de mudanças conflitantes aconteceu foi marcada com marcadores & lt; & lt; & lt; & lt; & lt; & lt; =======, e & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; . A parte antes do ======= é tipicamente seu lado, e a parte mais tarde é normalmente o lado deles.
O formato padrão não mostra o que o original disse na área conflitante. Você não pode dizer quantas linhas são excluídas e substituídas pela observação da Barbie & # 8217; do seu lado. A única coisa que você pode dizer é que seu lado quer dizer que é difícil e prefere ir às compras, enquanto o outro lado quer dizer que é fácil.
Um estilo alternativo pode ser usado definindo a variável de configuração "merge. conflictStyle" para "diff3". No estilo "diff3", o conflito acima pode parecer assim:
Em adição ao & lt; & gt; lt; & lt; & lt; & lt; =======, e & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; marcadores, usa outro ||||||| marcador que é seguido pelo texto original. Você pode dizer que o original apenas declarou um fato, e seu lado simplesmente cedeu a essa declaração e desistiu, enquanto o outro lado tentou ter uma atitude mais positiva. Às vezes, você pode encontrar uma melhor resolução ao visualizar o original.
COMO RESOLVER CONFLITOS.
Depois de ver um conflito, você pode fazer duas coisas:
Decida não se fundir. As únicas limpezas que você precisa são para redefinir o arquivo de índice para a confirmação HEAD para inverter 2. e para limpar as mudanças na árvore de trabalho feitas em 2. e 3; git merge - abort pode ser usado para isso.
Resolva os conflitos. Git marcará os conflitos na árvore de trabalho. Edite os arquivos em forma e git adicione-os ao índice. Use git commit ou git merge - continue para selar o negócio. O último comando verifica se existe uma mesclagem (interrompida) em andamento antes de ligar a confirmação git.
Você pode trabalhar com o conflito com várias ferramentas:
Use um mergethool. git mergetool para lançar um mergethool gráfico que irá ajudá-lo através da fusão.
Olhe para os diffs. Git diff mostrará um diferencial de três vias, destacando as mudanças nas versões HEAD e MERGE_HEAD.
Olhe os diffs de cada ramo. git log --merge - p & lt; path & gt; mostrará diffs primeiro para a versão HEAD e depois a versão MERGE_HEAD.
Veja os originais. git show: 1: o nome do arquivo mostra o antepassado comum, git show: 2: o nome do arquivo mostra a versão HEAD e o show git: 3: o nome do arquivo mostra a versão MERGE_HEAD.
Misture correções de ramos e aprimoramentos em cima do ramo atual, fazendo uma mesclagem de polvo:
Junte o ramo obsoleto no ramo atual, usando a nossa estratégia de fusão:
Junte o maint do ramo no ramo atual, mas não faça um novo commit automaticamente:
Isso pode ser usado quando você deseja incluir mais mudanças na mesclagem ou deseja escrever sua própria mensagem de confirmação de mesclagem.
Você deve abster-se de abusar dessa opção para esconder mudanças substanciais em uma comissão de mesclagem. Pequenos arranjos, como tropeçar o nome da versão / versão, seriam aceitáveis.
MERGE ESTRATÉGIAS.
O mecanismo de mesclagem (git misture e git pull commands) permite que as estratégias de mesclagem do backend sejam escolhidas com a opção - s. Algumas estratégias também podem tomar suas próprias opções, que podem ser aprovadas ao dar - X & lt; option & gt; argumentos para combinar e / ou git pull.
Isso só pode resolver duas cabeças (ou seja, o ramo atual e outro ramo que você retirou) usando um algoritmo de mesclagem de 3 vias. Ele tenta detectar cuidadosamente as ambiguidades de mesclagem cruzada e é considerado geralmente seguro e rápido.
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:
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.
Este é o oposto do nosso; note que, ao contrário do nosso, não há nenhum deles para se confundir com esta opção de mesclagem.
Com esta opção, a fusão-recursiva gasta um pouco de tempo extra para evitar mismerges que às vezes ocorrem devido a linhas de correspondência sem importância (por exemplo, chaves de funções distintas). Use isso quando os ramos a serem fundidos divergiram de forma selvagem. Veja também git-diff [1] - paciência.
Diz a fusão-recursiva para usar um algoritmo de diferença diferente, o que pode ajudar a evitar mismerges que ocorrem devido a linhas de correspondência sem importância (como chaves de funções distintas). Veja também git-diff [1] --diff-algorithm.
ignore-space-change ignore-all-space ignore-space-at-eol.
Trata as linhas com o tipo de mudança de espaço indicado como inalterada por causa de uma fusão de três vias. As mudanças de espaço em branco misturadas com outras alterações em uma linha não são ignoradas. Veja também git-diff [1] - b, - w e --ignore-space-at-eol.
Se sua versão apenas introduzir mudanças de espaço em uma linha, nossa versão é usada;
Se a nossa versão introduzir mudanças no espaço em branco, mas a sua versão inclui uma alteração substancial, sua versão é usada;
Caso contrário, a fusão prossegue da maneira usual.
Isso executa um check-out virtual e check-in de todos os três estágios de um arquivo ao resolver uma mesclagem de três vias. Esta opção destina-se a ser usada quando mesclar ramos com diferentes filtros limpos ou regras de normalização de fim de linha. Consulte "Mesclando ramos com diferentes atributos check-in / checkout" em gitattributes [5] para detalhes.
Desativa a opção renormalize. Isso substitui a variável de configuração fusionar.
Desative a detecção de renomeação. Veja também git-diff [1] --no-renomeação.
Ativar a detecção de renomeação, opcionalmente, definir o limite de similaridade. Este é o padrão. Veja também git-diff [1] --find-renames.
Sinônimo desaprovado para find-renames = & lt; n & gt; .
Esta opção é uma forma mais avançada de estratégia de subárvore, onde a estratégia adivinha a forma como duas árvores devem ser deslocadas para combinar uma com a outra ao fundir. Em vez disso, o caminho especificado é prefixado (ou despojado desde o início) para tornar a forma de duas árvores coincidir.
Isso resolve casos com mais de duas cabeças, mas se recusa a fazer uma fusão complexa que precisa de resolução manual. É principalmente destinado a ser usado para agrupar as cabeças de tópicos. Essa é a estratégia de mesclagem padrão ao puxar ou juntar mais de uma ramificação.
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.
Esta é uma estratégia recursiva modificada. Ao mesclar as árvores A e B, se B corresponde a uma subárvore de A, B é primeiro ajustado para coincidir com a estrutura em árvore de A, em vez de ler as árvores no mesmo nível. Este ajuste também é feito para a árvore-antepassada comum.
Com as estratégias que utilizam a fusão de 3 vias (incluindo o padrão, recursivo), se uma alteração for feita em ambos os ramos, mais tarde, revertida em um dos ramos, essa alteração estará presente no resultado mesclado; Algumas pessoas acham esse comportamento confuso. Ocorre porque apenas as cabeças e a base de mesclagem são consideradas ao realizar uma mesclagem, e não o indivíduo comete. O algoritmo de mesclagem considera, portanto, a alteração revertida como nenhuma alteração, e substitui a versão alterada.
CONFIGURAÇÃO.
Especifique o estilo em que os tipos de conflitos são escritos nos arquivos da árvore de trabalho após a mesclagem. O padrão é "fundir", o que mostra um & lt; & lt; & lt; & lt; & lt; & lt; marcador de conflito, mudanças feitas por um lado, um marcador ======, mudanças feitas pelo outro lado, e então um & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; & gt; marcador. Um estilo alternativo, "diff3", acrescenta um ||||||| marcador e o texto original antes do marcador =======.
Se a fusão for chamada sem qualquer argumento de confirmação, mescla os ramos a montante configurados para o ramo atual usando seus últimos valores observados armazenados em seus ramos de rastreamento remoto. Os valores do ramo. & Lt; ramo atual & gt;.merge esse nome dos ramos no controle remoto chamado por ramo. & Lt; branch atual & gt;.remote são consultados, e então eles são mapeados por controle remoto. & Lt; remote & gt ;.fetch to their correspondentes ramos de rastreamento remoto, e as dicas desses ramos de rastreamento são mescladas.
Por padrão, o Git não cria um commit de mesclagem extra ao mesclar um commit que é um descendente do commit atual. Em vez disso, a ponta do ramo atual é encaminhada rapidamente. Quando configurado como falso, esta variável diz ao Git que crie um commit de mesclagem extra nesse caso (equivalente a dar a opção --no-ff a partir da linha de comando). Quando configurado apenas, somente essas fusões de avanço rápido são permitidas (equivalente a dar a opção --ff-only da linha de comando).
Além dos nomes de ramificação, preencha a mensagem de log com o texto de descrição de ramificação associado a eles. Padrão para falso.
Além dos nomes de ramificação, preencha a mensagem de log com, no máximo, o número especificado de descrições de uma linha dos compromissos reais que estão sendo mesclados. O padrão é falso, e o verdadeiro é um sinônimo para 20.
O número de arquivos a serem considerados ao realizar a detecção de renomeação durante uma mesclagem; se não for especificado, o valor padrão do diff. renameLimit é o padrão.
Diga a Git que a representação canônica de arquivos no repositório mudou ao longo do tempo (por exemplo, comete início a registrar arquivos de texto com finais de linha CRLF, mas os recentes usam terminais de linha LF). Em tal repositório, o Git pode converter os dados gravados em compromissos em uma forma canônica antes de realizar uma mesclagem para reduzir conflitos desnecessários. Para obter mais informações, consulte a seção "Mesclar ramos com diferentes atributos check-in / checkout" em gitattributes [5].
Quer imprimir o diffstat entre ORIG_HEAD e o resultado de mesclagem no final da mesclagem. Verdadeiro por padrão.
Os controles que a ferramenta de mesclagem são usados ​​pelo git-mergetool [1]. A lista abaixo mostra os valores incorporados válidos. Qualquer outro valor é tratado como uma ferramenta de mesclagem personalizada e requer que uma variável correspondente correspondente seja definida.
Controla a quantidade de saída mostrada pela estratégia de fusão recursiva. O nível 0 não produz nada exceto uma mensagem de erro final se conflitos foram detectados. O Nível 1 produz apenas conflitos, 2 conflitos de saida e alterações de arquivos. O nível 5 e acima fornece informações de depuração. O padrão é o nível 2. Pode ser substituído pela variável de ambiente GIT_MERGE_VERBOSITY.
Define um nome legível para humanos para um driver de mesclagem de baixo nível personalizado. Veja gitattributes [5] para detalhes.
Define o comando que implementa um driver de mesclagem de baixo nível personalizado. Veja gitattributes [5] para detalhes.
Nomeia um driver de mesclagem de baixo nível para ser usado ao realizar uma mesclagem interna entre ancestros comuns. Veja gitattributes [5] para detalhes.
Define as opções padrão para a fusão em branch & lt; name & gt ;. A sintaxe e as opções suportadas são iguais às da git merge, mas os valores de opções que contêm caracteres de espaços em branco atualmente não são suportados.

estratégia de fusão Git recursiva
Obter através da App Store Leia esta publicação em nosso aplicativo!
Quando você usaria as diferentes estratégias de fusão de git?
Na página man no git-merge, existem várias estratégias de mesclagem que você pode usar.
resolver - Isso só pode resolver duas cabeças (ou seja, o ramo atual e outro ramo que você retirou) usando o algoritmo de mesclagem de 3 vias. Ele tenta detectar cuidadosamente as ambiguidades de mesclagem cruzada 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 antepassado comum que pode ser usado para a fusão 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 mesclagem sem causar mis-merges 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.
polvo - Isso resolve mais do que o caso de duas cabeças, mas se recusa a fazer uma fusão complexa que precisa de resolução manual. É principalmente destinado a ser usado para agrupar as cabeças de tópicos. Esta é a estratégia de mesclagem padrão ao puxar ou combinar mais de um ramo.
nosso - Isso resolve qualquer número de cabeças, mas o resultado da fusão é sempre a cabeça atual do ramo. É destinado a substituir o antigo histórico de desenvolvimento de filiais laterais.
subárvore - Esta é uma estratégia recursiva modificada. Ao mesclar as árvores A e B, se B corresponde a uma subárvore de A, B é primeiro ajustado para coincidir com a estrutura em árvore de A, em vez de ler as árvores no mesmo nível. Este ajuste também é feito para a árvore-antepassada comum.
Quando devo especificar algo diferente do padrão? Para quais cenários os melhores?
Não estou familiarizado com a resolução, mas usei os outros:
Recursivo é o padrão para fusões não rápidas. Todos estamos familiarizados com esse.
Eu usei polvo quando eu tive várias árvores que precisavam ser mescladas. Você vê isso em projetos maiores, onde muitas filiais tiveram desenvolvimento independente e está tudo pronto para se juntar em uma única cabeça.
Um ramo de polvo combina várias cabeças em um commit, desde que possa fazê-lo de forma limpa.
Para ilustração, imagine que você tenha um projeto que tenha um mestre e, em seguida, três ramos para fundir em (chame-os a, b e c).
Uma série de fusões recursivas pareceria assim (note que a primeira fusão foi um avanço rápido, pois não forcei a recursão):
No entanto, uma única fusão de polvo ficaria assim:
O nosso == Eu quero puxar outra cabeça, mas jogar 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: nem sequer olha para as mudanças entre esses ramos. Os ramos são apenas mesclados e nada é feito para os arquivos. Se você quer fundir no outro ramo e toda vez que há a pergunta "nossa versão de arquivo ou sua versão "você pode usar git merge - X nossa)
A subárvore é útil quando você quer mesclar em outro projeto em um subdiretório do seu projeto atual. Útil quando você tem uma biblioteca que você não deseja incluir como um submodulo.
Na verdade, as únicas duas estratégias que você gostaria de escolher são nossas se você quiser abandonar as mudanças trazidas por ramo, mas mantenha o ramo no histórico e a subárvore se você estiver mesclando o projeto independente no subdiretório do superprojeto (como 'git-gui' em ' git 'repositório).
O octopus Merge é usado automaticamente ao combinar mais de dois ramos. A resolução está aqui principalmente por razões históricas, e para quando você é atingido por casos de canto de estratégia de fusão recursiva.
"Resolve" vs estratégia de fusão "recursiva".
Recursivo é a atual estratégia padrão de duas cabeças, mas depois de algumas pesquisas, finalmente encontrei algumas informações sobre a estratégia de "resolver".
Originalmente, "resolver" era a estratégia padrão para fusões Git.
Em situações de fusão cruzada, onde há mais de uma possível base de mesclagem, a estratégia de resolução funciona assim: escolha uma das possíveis bases de mesclagem e espere o melhor. Isso na verdade não é tão ruim quanto parece. Muitas vezes, os usuários estão trabalhando em diferentes partes do código. Nesse caso, o Git detecta que está relembrando algumas mudanças que já estão em vigor e ignora as mudanças 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 funcionei com sucesso árvores usando "resolver" que falhou com a estratégia recursiva padrão. Eu estava ficando fatal: git write-tree não conseguiu escrever erros na árvore, e graças a esta postagem no blog (mirror) tentei "-s resolve", que funcionou. Ainda não sei exatamente por quê. mas acho que foi porque eu tive mudanças duplicadas em ambas as árvores e resolvi as "ignoradas" adequadamente.

МОДЕРАТОРЫ.
Bem-vindo ao Reddit,
a primeira página da internet.
e inscreva-se em uma das milhares de comunidades.
Quer adicionar à discussão?
помощь правила сайта центр поддержки вики реддикет mod guidelines связаться с нами.
приложенияи инструменты Reddit para iPhone Reddit para o site móvel Android кнопки.
Использование данного сайта означает, что вы принимаете & # 32; пользовательского соглашения & # 32; и & # 32; Политика конфиденциальности. &cópia de; 2017 reddit инкорпорейтед. Все права защищены.
REDDIT e o logotipo ALIEN são marcas registradas da reddit inc.
& pi; Renderizado pelo PID 100768 em & # 32; app-323 & # 32; 2017-12-19 20: 39: 08.071930 + 00: 00 executando o código do país 9e1524e: UA.