TL; DR;
Para resumir (como Benubird comenta ), quando:
git checkout A
git rebase B # rebase A on top of B
localé B(rebase para ),remote é A
E:
git checkout A
git merge B # merge B into A
localé A(intercalação em ),remote é B
Uma rebase muda ours(a ramificação atual antes do início da rebase) e theirs(a ramificação na qual você deseja rebase).
O kutschkem ressalta que, em um contexto de fusão de ferramentas da GUI :
- referências locais confirmadas parcialmente reformuladas : "
ours" (a ramificação upstream)
- remoto refere-se às alterações recebidas : "
theirs" - a ramificação atual antes da rebase.
Veja ilustrações na última parte desta resposta.
Inversão quando rebase
A confusão pode estar relacionada à inversão ourse theirsdurante uma rebase .
(extratos relevantes)
git rebasepágina de manual :
Observe que uma mesclagem de rebase funciona repetindo cada confirmação da ramificação de trabalho na parte superior da <upstream>ramificação.
Por esse motivo, quando ocorre um conflito de mesclagem:
- o lado relatado como "
ours" é a série rebaseada até agora, começando com <upstream>,
- e '
theirs' é o ramo de trabalho. Em outras palavras, os lados são trocados.
Inversão ilustrada
Em uma mesclagem
x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
, não alteramos o ramo atual 'B'; portanto, o que temos ainda é o que estávamos trabalhando (e nos fundimos de outro ramo)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
Em uma rebase:
Mas, em uma rebase , trocamos de lado, porque a primeira coisa que uma rebase faz é fazer o checkout da ramificação upstream! (para reproduzir as confirmações atuais em cima dela)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
A git rebase upstreammudará primeiro HEADde B para o ramo upstream HEAD(daí a troca de 'nosso' e 'deles' em comparação com o ramo de trabalho "atual" anterior).)
x--x--x--x--x <- former "current" branch, new "theirs"
\
\
\--y--y--y(*) <- upstream branch with B reset on it,
new "ours", to replay x's on it
, e a rebase repetirá os "commits" deles na nova ramificação "our" B:
x--x..x..x..x <- old "theirs" commits, now "ghosts", available through reflogs
\
\
\--y--y--y--x'--x'--x'(*) <- branch B with HEAD updated ("ours")
^
|
upstream branch
Nota: a noção "upstream" é o conjunto referencial de dados (um repositório all ou, como aqui, uma ramificação, que pode ser uma ramificação local ) a partir da qual os dados são lidos ou aos quais novos dados são adicionados / criados.
' local' e ' remote' vs. ' mine' e ' theirs'
Pandawood acrescenta nos comentários :
Para mim, a questão ainda permanece, que é "local" e quem é "remoto" (uma vez que os termos "nosso" e "deles" não são usados para rebasear no git, referir-se a eles parece tornar a resposta mais confusa) .
GUI git mergetool
kutschkem acrescenta, e com razão:
Ao resolver conflitos, o git dirá algo como:
local: modified file and remote: modified file.
Tenho certeza de que a pergunta visa a definição de local e remoto neste momento. Nesse ponto, parece-me, pela minha experiência, que:
- referências locais confirmadas parcialmente reformuladas : "
ours" (a ramificação upstream)
- remoto refere-se às alterações recebidas : "
theirs" - a ramificação atual antes da rebase.
git mergetoolde fato menciona 'local' e 'remote' :
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
Por exemplo, o KDiff3 iria exibir a resolução merge como assim :
E fusão iria exibi-lo também :
O mesmo para o VimDiff , que exibe :
Invoque o Vimdiff como uma ferramenta de fusão com o git mergetool -t gvimdiff. Versões recentes do Git invocam o Vimdiff com o seguinte layout de janela:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL:
Um arquivo temporário que contém o conteúdo do arquivo na ramificação atual.BASE:
Um arquivo temporário que contém a base comum para a mesclagem.REMOTE:
Um arquivo temporário que contém o conteúdo do arquivo a ser mesclado.MERGED:
O arquivo que contém os marcadores de conflito.
O Git executou o máximo possível de resolução automática de conflitos e o estado desse arquivo é uma combinação de ambos LOCALe de REMOTEmarcadores de conflito em torno de qualquer coisa que o Git não pudesse resolver por si próprio.
O mergetooldeve gravar o resultado da resolução neste arquivo.
