Git

git-merge last updated in 2.43.0

NOME

git-merge - Une dois ou mais históricos de desenvolvimento

RESUMO

git merge [-n] [--stat] [--no-commit] [--squash] [--[no-]edit]
	[--no-verify] [-s <estratégia>] [-X <opção-da-estratégia>] [-S[<keyid>]]
	[--[no-]allow-unrelated-histories]
	[--[no-]rerere-autoupdate] [-m <msg>] [-F <arquivo>] [<commit>…]
git merge (--continue | --abort | --quit)

DESCRIÇÃO

Incorpora as alterações dos commits citados (desde o momento em que os seus históricos divergirem do ramo atual) para dentro do ramo atual. Este comando é utilizado pelo git pull para incorporar as alterações vindos de outro repositório e pode ser utilizado manualmente para mesclar as alterações do outro ramo para um outro.

Suponha que exista o seguinte histórico e o ramo atual seja master:

	  A---B---C topic
	 /
    D---E---F---G master

Em seguida, git merge topic repetirá as alterações feitas no ramo topic uma vez que ele divergiu de master (ou seja,E) até que o seu commit atual (C) no topo do master registrando o resultado em um novo commit junto com os nomes de dois commits relacionados em uma mensagem log vindo do usuário descrevendo as alterações.

	  A---B---C topic
	 /         \
    D---E---F---G---H master

A segunda sintaxe ("git merge --abort") só pode ser executada após o resultado da mesclagem apresentar conflitos. O comando git merge abort abortará o processo de mesclagem e tentará reconstruir a condição anterior a mesclagem. No entanto, Caso haja alterações com commits não realizados quando a mesclagem for iniciada (e especialmente caso estas alterações forem modificadas posteriormente após o início da mesclagem), o git merge abort será, em alguns casos, incapaz de reconstruir as alterações originais (pré-mesclagem). Portanto:

Aviso: É desencorajado executar o comando git merge com alterações não-triviais dos commits que não foram feitos é desencorajado: enquanto possível, pode deixá-lo em uma condição difícil de sair no caso de haver um conflito.

A terceira sintaxe ("git merge --continue") só pode ser executada depois que a mesclagem apresentar conflitos.

OPÇÕES

--commit
--no-commit: Execute a mesclagem e faça o commit com o resultado. Esta opção pode ser usada para substituir a opção --no-commit.

Com a opção --no-commit, executa a mesclagem e para imediatamente antes de criar a mesclagem de um commit, para dar ao usuário a chance de inspecionar e ajustar ainda mais o resultado da mesclagem antes de fazer o commit.

Observe que as atualizações com avanço rápido não criam a mesclagem de um commit e portanto, não há como interromper essas mesclagens com a opção --no-commit. Portanto, caso queira garantir que o seu ramo não seja alterado ou atualizado pelo comando mesclar, utilize --no-ff with --no-commit.
--edit
-e
--no-edit: Chame um editor antes de fazer a mesclagem mecânica de um commit bem sucedido para editar ainda mais a mensagem da mesclagem que foi gerada automaticamente, para que o usuário possa explicar e justificar a mesclagem. A opção --no-edit pode ser utilizada para aceitar a mensagem que foi gerada automaticamente (em geral isso é desencorajado). A opção --edit (ou -e) ainda é útil caso esteja enviando uma mensagem de rascunho com a opção -m na linha de comando e queira 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 do registro log da mesclagem. Eles verão um editor aberto quando executar o git merge. Para facilitar o ajuste destes scripts para o comportamento que foi atualizado, a variável de ambiente GIT_MERGE_AUTOEDIT pode ser definido como no no início deles.
--cleanup=<modo>: Esta opção determina como a mensagem de mesclagem será limpa antes da confirmação. Para mais detalhes consulte git-commit[1]. Além disso, caso o <mode> seja dado o valor de scissors, scissors (tesouras) será anexada a MERGE_MSG antes de ser repassada para o mecanismo de commit caso exista mesclagens conflitantes.
--ff
--no-ff
--ff-only: Especifica como uma mesclagem é manipulada quando o histórico mesclado já é um descendente do histórico atual. A predefinição é a opção --ff , a menos que durante a mesclagem de uma tag anotada (e possivelmente assinada) que não seja armazenada em seu local natural na hierarquia refs/tags/, no caso onde a opção --ff não será assumida.

Com --ff, quando for possível, resolva a mesclagem como um avanço rápido (atualize apenas o ponteiro do ramo para coincidir com a ramificação que foi mesclada; não crie um commit da mesclagem). Quando não for possível (quando o histórico mesclado não for um descendente do histórico atual), crie um commit da mesclagem.

Com --no-ff, crie um commit da mesclagem em todos os casos, mesmo quando a mesclagem puder ser resolvida como um avanço rápido.

Com a opção --ff-only, quando for possível, resolva a mesclagem com avanço rápido. Quando não for possível, recuse a mesclagem e encerre com uma condição diferente de zero.
-S[<keyid>]
--gpg-sign[=<keyid>]
--no-gpg-sign: Assine a mesclagem resultante do commit com o GPG. O argumento keyid é opcional e a predefinição retorna para a identidade de quem fez o commit; se utilizado, deve estar anexado a opção sem espaço. A opção --no-gpg-sign é útil para revogar a variável de configuração commit.gpgSign e a anterior --gpg-sign.
--log[=<n>]
--no-log: Além dos nomes dos ramos, preencha a mensagem do registro log com descrições de uma linha com no máximo <n> commits atuais que estão sendo mesclados. Consulte também git-fmt-merge-msg[1].

Com --no-log, não liste as descrições de uma linha vindas do commits que estão atualmente sendo mescladas.
--signoff
--no-signoff: Adicionar uma linha assinado pela pessoa que fez o commit no final do registro log do commit assinado. O significado de uma aprovação depende do projeto, porém normalmente certifica que a pessoa que fez o commit tem o direito de enviar este trabalho sob a mesma licença e concorda com um Certificado de Origem do Desenvolvedor (consulte http://developercertificate.org/ para obter mais informações).

A opção --no-signoff não adiciona a linha de assinatura "Signed-off-by".
--stat
-n
--no-stat: Exiba um "diffstat" no final da mesclagem. O diffstat também é controlado pela opção da configuração merge.stat.

Com -n ou --no-stat, não mostre o diffstat no final da mesclagem.
--squash
--no-squash: Produza a árvore de trabalho e a condição do índice como se uma mesclagem real tivesse acontecido (exceto as informações da mesclagem), porém não efetue um commit, mova o HEAD ou registre o $GIT_DIR/MERGE_HEAD (para causar o próximo comando git commit para criar uma mesclagem). Isso permite que você crie um único commit sobre o ramo atual, cujo efeito é o mesmo que mesclar um outro ramo (ou mais no caso da mesclagem "octopus").

Com a opção --no-squash, execute a mesclagem e faça o commit com o resultado. Esta opção pode ser usada para substituir a opção --squash.

Com a opção --squash, a opção --commit não é permitida e irá falhar.
--no-verify: Esta opção ignora os ganchos dos commits anteriores e os ganchos das mensagens do commit. Consulte também githooks[5].
-s <estratégia>
--strategy=<estratégia>: Use a estratégia de mesclagem informada; podem ser utilizado mais de uma vez para defini-los na ordem em que devem ser tentados. Caso não haja a opção -s, em vez disso será usada uma lista de estratégias incorporada (git merge-recursive ao mesclar um único cabeçalho, caso contrário git merge octopus).
-X <opção>
--strategy-option=<opção>: Passe a opção específica da estratégia através da estratégia de mesclagem.
--verify-signatures
--no-verify-signatures: Verifique se o topo do commit do lado do ramo mesclado está assinado com uma chave válida, ou seja, uma chave que possua um uid válida: no modelo de confiança predefinido, isso significa que a chave da assinatura foi assinada através de uma chave confiável. Caso o topo do commit do lado do ramo não seja assinada com uma chave válida, a mesclagem será cancelada.
--summary
--no-summary: É um sinônimos para --stat e --no-stat; estas opções foram descontinuadas e serão removidas no futuro.
-q
--quiet: Opere em silêncio. Implica no uso da opção --no-progress.
-v
--verbose: Seja loquaz.
--progress
--no-progress: Ativa/desativa o progresso de maneira explicita. Se nenhum seja definido, o progresso será exibido caso o erro predefinido esteja conectado a um terminal. Observe que nem todas as estratégias de mesclagem podem se compatíveis com os relatórios de progresso.
--autostash
--no-autostash: Automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run the operation on a dirty worktree. No entanto, utilize com cuidado: conflitos não triviais podem acontecer caso a aplicação final do "stash" ocorra após uma mesclagem bem-sucedida.
--allow-unrelated-histories: É predefinido que o comando git merge se recuse a mesclar os históricos que não compartilham de um ancestral comum. Esta opção pode ser utilizada para substituir esta segurança durante a mesclagem dos históricos dos dois projetos que iniciaram as suas vidas de forma independente. Como esta é uma ocasião muito rara, não existe variável de configuração para ativar isso de forma predefinida e não será adicionada.

-m <msg>: Defina a mensagem do commit que será utilizada para a mesclagem do commit (no caso de uma ser criada).

Caso --log seja utilizado, um atalho dos commits que estão sendo mesclados será anexado à mensagem informada.

O comando git fmt-merge-msg pode ser utilizado para informar uma boa predefinição para as invocações automatizadas do comando git merge. A mensagem automatizada pode incluir a descrição da ramificação.
-F <arquivo>
--file=<arquivo>: Leia a mensagem de commit que será utilizada para mesclar o commit (no caso de uma ser criada).

Caso --log seja utilizado, um atalho dos commits que estão sendo mesclados será anexado à mensagem informada.
--rerere-autoupdate
--no-rerere-autoupdate: Permita que o mecanismo "rerere" atualize o índice com o resultado da resolução automática de conflitos, caso seja possível.
--overwrite-ignore
--no-overwrite-ignore: Silently overwrite ignored files from the merge result. Este é o comportamento predefinido. Use --no-overwrite-ignore to abort.
--abort: Interrompa o processo atual da resolução de conflitos e tente reconstruir a condição de pré-mesclagem. Caso uma entrada de "autostash" esteja presente, aplique-a à árvore de trabalho.

Caso haja commits não realizados presentes na árvore de trabalho quando a mesclagem for iniciada, o comando git merge --abort será, em alguns casos, incapaz de reconstruir essas alterações. Portanto, é recomendável sempre fazer o commit ou acumular as suas alterações antes de executar o git merge.

O comando git merge --abort é o equivalente ao git reset --merge quando MERGE_HEAD estiver presente ou a menos que o MERGE_AUTOSTASH também esteja; neste caso, o comando git merge --abort aplica a entrada stash na área de trabalho enquanto git reset --merge salvará as alterações acumuladas na lista do estoque.
--quit: Não se preocupa com a mesclagem em andamento. Mantenha o índice e a árvore de trabalho como estão. Caso MERGE_AUTOSTASH esteja presente, os lançamentos armazenados serão salvos na lista do estoque (stash list).
--continue: Depois que um git merge for interrompido por causa dos conflitos, é possível concluir a mesclagem executando o comando git merge --continue (consulte a seção "COMO RESOLVER CONFLITOS" abaixo).
<commit>…: Os commits, geralmente outros cabeçalhos do ramo que serão mesclados na nossa filial. A especificação de mais de um commit criará uma mesclagem com mais de duas origens (carinhosamente chamada de mesclagem polvo (octopus merge)).

Caso nenhum commit seja informado na linha de comando, mescle as ramificações monitoradas remotamente para que a ramificação atual esteja configurada para ser utilizada como sua upstream. Consulte também a seção de configuração desta página do manual.

Quando FETCH_HEAD (e nenhum outro commit) for definido, as ramificações registradas no arquivo .git/FETCH_HEAD através da invocação anterior para mesclagem com o comando git fetch, serão mescladas no ramo atual.

VERIFICAÇÕES PRÉVIAS DA MESCLAGEM

Você deve ter o seu próprio trabalho em boas condições e com o commit feito localmente antes de aplicar as alterações externas, para evitar que sejam sobrescritos no caso da existência de conflitos. Consulte também git-stash[1]. Os comandos git pull e git merge ficarão inertes sem fazer nada quando as modificações dos commits que não foram aplicados localmente se sobrepuserem aos arquivos que os comandos git pull/git merge talvez precisem atualizar.

Para evitar o registro de alterações não relacionadas a mesclagem do commit, os comandos git pull e git merge também serão cancelados caso exista alguma alteração registrada no índice em relação ao commit HEAD. (Podem existir algumas poucas exceções especiais a essa regra dependendo de qual estratégia de mesclagem estiver em uso, no geral, o índice deve corresponder ao HEAD.)

Caso todos os commits sejam antecessores ao HEAD, então o comando git merge encerrara prematuramente exibindo a mensagem "Já foi atualizado"

MESCLAGEM COM AVANÇO RÁPIDO

Frequentemente, o cabeçalho do ramo atual é um ancestral do commit informado. Este é o caso mais comum especialmente quando invocado a partir do comando git pull: você está monitorando um repositório upstream, não efetuou as alterações locais e agora deseja atualizar para uma revisão upstream mais recente. Nesse caso, não é necessário um novo commit para armazenar o histórico combinado; em vez disso, o HEAD (junto com o índice) é atualizado para apontar para o commit informado sem criar uma mesclagem extra do commit.

Este comportamento pode ser suprimido ao usar a opção --no-ff.

MESCLAGEM REAL

Exceto em uma mesclagem de avanço rápido (veja acima), as ramificações que serão mescladas devem ser vinculadas através de uma consolidação da mesclagem que tenha ambas como as suas origens.

Uma versão mesclada que reconcilia as alterações de todas as ramificações que serão mescladas, o commit é feito e o seu HEAD, índice e a árvore de trabalho são atualizados para ela. É possível ter alterações na árvore de trabalho, desde que não se sobreponham; a atualização irá preservá-las.

Quando não é óbvio como reconciliar as alterações, acontece o seguinte:

O indicador do HEAD se mantém o mesmo.
O "ref" do MERGE_HEAD é definido para indicar o HEAD do outro ramo.
Os caminhos que foram mesclados corretamente são atualizados no arquivo do índice e na sua árvore de trabalho.
Para os caminhos conflitantes, o arquivo do índice registra até três versões: o estágio 1 armazena a versão do ancestral comum, o estágio 2 do 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 "merge"; ou seja, os resultados da mesclagem em três direções com os marcadores de conflito familiares <<<, === e >>>.
Nenhuma outra alteração é feita. Em particular, as alterações locais que você tinha antes de iniciar a mesclagem permanecerão as mesmas e as entradas do índice para elas permanecerão como estavam, ou seja, correspondendo com `HEAD '.

Caso tenha tentado uma mesclagem que resultou em conflitos complexos e queira recomeçar, execute o comando git merge --abort.

MESCLANDO TAG

Ao mesclar uma tag anotada (e possivelmente assinada), o Git sempre cria a mesclagem de um commit, mesmo que seja possível realizar uma mesclagem de avanço rápido, o modelo da mensagem do commit é preparado com a mensagem da tag. Além disso, caso a tag esteja assinada, a verificação da assinatura será relatada como um comentário no modelo de mensagem. Consulte também git-tag[1].

Quando você deseja apenas integrar-se ao trabalho que leva ao commit que está marcado, por exemplo, sincronizando com um ponto de liberação upstream, talvez você não queira fazer uma consolidação desnecessária da mesclagem.

Neste caso, você pode "desembrulhar" a etiqueta antes de encaminhá-la para o comando git merge ou passar ao --ffff-only quando você não tiver nenhum trabalho feito por conta própria. por exemplo.

git fetch origin
git merge v1.2.3^0
git merge --ff-only v1.2.3

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 alterações feitas no ancestral da versão comum, as que não se sobrepõem (ou seja, você alterou uma área do arquivo enquanto o outro lado deixou a área intacta ou vice-versa) são incorporadas no resultado final, literalmente. Quando os dois lados que fizeram as alterações na mesma área, porém, o Git não pode escolher aleatoriamente um lado sobre o outro e solicita que você o resolva, deixando intacto o que os dois lados fizeram nessa área.

É predefinido que o Git utilize o mesmo estilo que o utilizado pelo programa "merge" (mesclar) do conjunto RCS para apresentar um pedaço conflitante, como este:

Aqui estão as linhas que não são alteradas em relação ao ancestral
comum ou resolvido de maneira limpa porque apenas um lado mudou.
<<<<<<< yours:sample.txt
A resolução de conflitos é difícil;
vamos às compras.
=======
O Git facilita a resolução de conflitos.
>>>>>>> theirs:sample.txt
E aqui está outra linha que foi claramente resolvida ou não foi modificada.

A área onde ocorreu um para de alterações conflitantes é marcada com os marcadores <<<<<<<, ======= e >>>>>>>. A parte anterior ao ======= é tipicamente do seu lado e a parte posterior é tipicamente do lado deles.

O formato predefinido não exibe o que o original disse na área conflitante. Você não pode dizer quantas linhas foram excluídas e substituídas através das observações do seu lado. A única coisa que é possível dizer é que o seu lado quer dizer que é difícil e você prefere ir às compras, enquanto o outro lado quer dizer que é fácil.

Um estilo alternativo pode ser utilizado ao definir a variável de configuração "merge.conflictStyle" como "diff3". No estilo "diff3", o conflito acima pode ser assim:

Aqui estão as linhas que não são alteradas em relação ao ancestral
comum ou resolvido de maneira limpa porque apenas um lado mudou.
<<<<<<< yours:sample.txt
A resolução de conflitos é difícil;
vamos às compras.
|||||||
A resolução de conflitos é difícil.
=======
O Git facilita a resolução de conflitos.
>>>>>>> theirs:sample.txt
E aqui está outra linha que foi claramente resolvida ou não foi modificada.

Além dos marcadores <<<<<<<, ======= e >>>>>>> , ele utiliza outro marcador `||||||| que é seguido pelo texto original. Você pode dizer que o original acabou de declarar um fato e o seu lado simplesmente cedeu a essa afirmação e desistiu, enquanto o outro lado tentou ter uma atitude mais positiva. Às vezes, você pode ter uma resolução melhor visualizando o original.

COMO RESOLVER OS CONFLITOS

Após encontrar um conflito, você pode fazer duas coisas:

Decida não fazer a mesclagem. As únicas limpezas necessárias são para redefinir o arquivo no índice para o commit HEAD para que 2 seja revertido. e para limpar as alterações na árvore de trabalho feitas por 2. e o 3 .; O git merge --abort pode ser utilizado para isso.
Resolva os conflitos. O Git marcará os conflitos na árvore de trabalho. Edite os arquivos em ordem e comando git add adiciona eles ao índice. Utilize o comando git commit ou git merge --continue para selar o acordo. O último comando verifica a existência de uma mesclagem (interrompida) em andamento antes de chamar o comando git commit.

Você pode trabalhar o conflito com uma quantidade de ferramentas:

Utilize uma ferramenta de mesclagem "mergetool". git mergetool para iniciar uma ferramenta gráfica para lhe auxiliar através do processo de mesclagem.
Veja as diferenças dos arquivos diff. O git diff exibirá um diff de três vias, destacando as alterações das versões` HEAD` e MERGE_HEAD.
Veja as diferenças de cada ramo. O comando git log --merge -p <caminho> exibirá as diferenças primeiro para a versão HEAD e depois para a versão MERGE_HEAD.
Consulte os originais. O comando git show :1:filename exibe o ancestral comum, git show :2:filename exibe a versão do HEAD e o git show :3:filename exibe a versão do MERGE_HEAD.

EXEMPLOS

Mescla as ramificações fixes e enhancements no cume do ramo atual, fazendo um conjunto de mesclagens:
```
$ git merge fixes enhancements
```
Mescle o ramo obsolete (obsoleto) no ramo atual, utilizando a nossa estratégia de mesclagem:
```
$ git merge -s ours obsolete
```
Mescla o ramo maint no ramo atual, porém não faça um novo commit de forma automática:
```
$ git merge --no-commit maint
```
Isso pode ser utilizado quando você queira incluir outras alterações na mesclagem ou se deseja, grave a sua própria mensagem do commit na mesclagem.

Você deve evitar abusar dessa opção para ocultar as alterações substanciais em uma mesclagem do commit. Pequenos reparos, como o nome da versão/revisão são aceitáveis.

ESTRATÉGIAS DE MESCLAGEM

O mecanismo da mesclagem (comandos git merge e git pull) permite que as estruturas das estratégias de mesclagem sejam escolhidas com a opção -s. Algumas estratégias também podem ter suas próprias opções, que podem ser passadas usando -X<opção> como argumentos para o comando git merge e/ou git pull.

resolve

Isso só pode resultar em dois cabeçalhos (ou seja, a ramificação atual e uma outra ramificada da que você obteve) utilizando um algoritmo de mesclagem de três vias. Ele tenta detectar cuidadosamente as ambiguidades cruzadas da mesclagem e geralmente é considerado seguro e rápido.

recursive

Isso pode resolver apenas duas cabeças usando o algoritmo da mesclagem de 3 vias. Quando há mais de um ancestral comum que pode ser usado para a mesclagem de 3 vias, ele cria uma árvore mesclada dos ancestrais comuns e o usa como a árvore de referência para a mesclagem de 3 vias. Foi informado que isso resulta em menos conflitos durante mesclagem sem causar distorções pelos testes feitos nas mesclagens reais dos commits, retiradas do histórico de desenvolvimento do Linux kernel 2.6. Além disso, isso pode detectar e manipular as mesclagens envolvendo renomeações, porém atualmente não pode fazer uso das cópias detectadas. Essa é a estratégia de mesclagem predefinida ao extrair ou mesclar um ramo.

A estratégia recursiva pode ter as seguintes opções:

ours

Esta opção impõem que os pedaços conflitantes que sejam resolvidos de forma automática e de maneira limpa, favorecendo a nossa versão. As alterações vindos de outra árvore que não conflitam com o nosso lado são refletidas no resultado da mesclagem. Para um arquivo binário, todo o conteúdo é retirado do nosso lado.

Isso não deve ser confundido com a estratégia da nossa de mesclagem, que sequer olha para o que a outra árvore contém. Descarta tudo o que a outra árvore fez, declarando que o nosso histórico contém tudo o que aconteceu nela.

theirs

Este é o oposto do nosso; observe que, diferentemente do nosso, não existe uma estratégia de mesclagem deles para confundir esta opção de mesclagem.

patience

Com esta opção, merge-recursive gasta um pouco de tempo extra para evitar as distorções que às vezes ocorrem devido as coincidência das linhas sem importância (como, por exemplo, chaves das funções distintas). Use isso quando os ramos que serão mesclados divergirem bastante. Consulte também git-diff[1] --patience.

diff-algorithm=[patience|minimal|histogram|myers]

Informa ao merge-recursive para usar um algoritmo diff diferente, que pode ajudar a evitar as distorções que ocorrem devido as linhas coincidentes sem importância (como chaves das funções distintas). Consulte também git-diff[1] --diff-algorithm.

ignore-space-change

ignore-all-space

ignore-space-at-eol

ignore-cr-at-eol

Trata as linhas com o tipo indicado da mudança do espaço como inalterado por uma mesclagem de três vias. As alterações de espaço combinadas com outras alterações em uma linha não são ignoradas. Consulte também git-diff[1] -b, -w, --ignore-space-at-eol, e --ignore-cr-at-eol.

Caso a versão their (dele) introduzir apenas as alterações de espaço em uma linha, a our (nossa) versão será utilizada;
Caso a our (nossa) versão introduzir alterações nos espaços, porém a versão their (dele) incluir uma alteração substancial, a versão their (dele) será utilizada;
Caso contrário, a mesclagem continuará de forma usual.

renormalize

Executa uma averiguação e um check-in virtual de três estágios em um arquivo ao resolver uma mesclagem de três vias. Esta opção deve ser utilizada ao mesclar os ramos com diferentes filtros que estejam limpos ou as regras normais para a quebra de linha. Para obter mais detalhes, consulte "Mesclando ramificações com diferentes atributos de check-in/check-out" em gitattributes[5].

no-renormalize

Desativa a opção renormalize. Substitui a variável de configuração merge.renormalize.

no-renames

Desativa a detecção de renomeação. Isso substitui a variável de configuração merge.renames. Consulte tambémgit-diff[1] --no-renames.

find-renames[=<n>]

Liga a detecção de renomeação, configurando opcionalmente o limite de similaridade. Esta é a predefinição. Isso substitui a configuração da variável merge.renames. Consulte também git-diff[1] --find-renames.

rename-threshold=<n>

É um sinônimo obsoleto para find-renames=<n>.

subtree[=<caminho>]

Essa opção é uma forma mais avançada da estratégia da subárvore, onde a estratégia adivinha como as duas árvores devem ser deslocadas para coincidirem uma com a outra durante a mesclagem. Em vez disso, o caminho definido é prefixado (ou removido desde o início) para criar a forma das duas árvores que serão coincididas.

octopus

Isso resolve os casos com mais de dois cabeçalhos, porém se recusa a fazer uma mesclagem complexa que precise de uma resolução manual. Destina-se primeiramente para ser usado para agrupar junto o tópico dos cabeçalhos. Esra é a estratégia de mesclagem predefinida durante a extração ou a mesclagem com mais de um ramo.

ours

Isso resolve qualquer quantidade dos cabeçalhos, porém a árvore resultante da mesclagem é sempre a do cabeçalho atual do ramo, ignorando efetivamente todas as alterações de todas os outros ramos. Ele deve ser usado para substituir o histórico antigo de desenvolvimento das ramificações laterais. Observe que isso é diferente da opção -Xours da estratégia de mesclagem recursiva.

subtree

Esta é uma estratégia recursiva modificada. Ao mesclar as árvores A e B, caso B corresponda a uma subárvore de A, o B será ajustado primeiro para coincidir à estrutura da árvore A, em vez de ler as árvores no mesmo nível. Esse ajuste também é feito na árvore ancestral comum.

Com as estratégias que usma a mesclagem de 3 vias (incluindo a predefinição, recursive), caso uma alteração seja feita em ambas as ramificações, porém depois revertida em uma das ramificações, essa alteração estará presente no resultado mesclado; algumas pessoas acham este comportamento confuso. Isso ocorre porque apenas os cabeçalhos e a base da mesclagem são consideradas ao fazer uma mesclagem, e não os commits individuais. Portanto, o algoritmo da mesclagem considera a alteração revertida como nenhuma alteração e substitui a versão alterada.

CONFIGURAÇÃO

Warning

Missing pt_BR/config/merge.txt

See original version for this content.

branch.<nome>.mergeOptions: Define as opções predefinidas de mesclagem no ramo <nome>. A sintaxe e as opções que são compatíveis são iguais às do git merge, porém atualmente os valores das opções que contêm os caracteres de espaço não são compatíveis.

VEJA TAMBÉM

git-fmt-merge-msg[1], git-pull[1], gitattributes[5], git-reset[1], git-diff[1], git-ls-files[1], git-add[1], git-rm[1], git-mergetool[1]

Parte do conjunto git[1]

Setup and Config

Getting and Creating Projects

Basic Snapshotting

Branching and Merging

Sharing and Updating Projects

Inspection and Comparison

Patching

Debugging

Email

External Systems

Server Admin

Guides

Administration

Plumbing Commands