TL; DR;
Para resumir (como comenta Benubird ), cuando:
git checkout A
git rebase B # rebase A on top of B
locales B(rebase en ),remote es A
Y:
git checkout A
git merge B # merge B into A
locales A(fusionarse con ),remote es B
Un cambio de base cambia ours(rama actual antes de que comience el rebase) y theirs(la rama sobre la que desea rebase).
kutschkem señala que, en un contexto mergetool GUI :
- referencias locales las confirmaciones parcialmente modificadas : "
ours" (la rama ascendente)
- control remoto se refiere a los cambios entrantes : "
theirs" - la rama actual antes del rebase.
Vea las ilustraciones en la última parte de esta respuesta.
Inversión cuando rebase
La confusión puede estar relacionada con la inversión de oursy theirsdurante un rebase .
(extractos relevantes)
git rebasepágina man :
Tenga en cuenta que una combinación de rebase funciona al reproducir cada confirmación de la rama de trabajo en la parte superior de la <upstream>rama.
Debido a esto, cuando ocurre un conflicto de fusión:
- el lado reportado como '
ours' es la serie rebase hasta ahora, comenzando con <upstream>,
- y '
theirs' es la rama de trabajo. En otras palabras, los lados se intercambian.
Inversión ilustrada
En una fusión
x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
, no cambiamos la rama actual 'B', así que lo que tenemos sigue siendo en lo que estábamos trabajando (y nos fusionamos desde otra rama)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
En un rebase:
Pero en un rebase , cambiamos de lado porque lo primero que hace un rebase es verificar la rama aguas arriba. (para reproducir las confirmaciones actuales encima)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
A git rebase upstreamprimero cambiará HEADde B a la rama aguas arriba HEAD(de ahí el cambio de 'la nuestra' y 'la de ellos' en comparación con la rama de trabajo "actual" 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
, y luego el rebase reproducirá 'sus' confirmaciones en la nueva rama 'nuestra' 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: la noción "ascendente" es el conjunto referencial de datos (un repositorio completo o, como aquí, una rama, que puede ser una rama local ) desde el que se leen los datos o se añaden / crean nuevos datos.
' local' y ' remote' vs. ' mine' y ' theirs'
Pandawood agrega en los comentarios :
Para mí, la pregunta sigue siendo, que es "local" y quién es "remoto" (ya que los términos "nuestro" y "suyo" no se usan cuando se rebase en git, referirse a ellos simplemente parece hacer una respuesta más confusa) .
GUI git mergetool
kutschkem agrega, y con razón:
Al resolver conflictos, git dirá algo como:
local: modified file and remote: modified file.
Estoy bastante seguro de que la pregunta apunta a la definición de local y remoto en este punto. En ese punto, me parece por experiencia que:
- referencias locales las confirmaciones parcialmente modificadas : "
ours" (la rama ascendente)
- control remoto se refiere a los cambios entrantes : "
theirs" - la rama actual antes del rebase.
git mergetoolde hecho menciona 'local' y 'remoto' :
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
Por ejemplo, KDiff3 sería mostrar la resolución de combinación como tal :
Y meld también lo mostraría :
Lo mismo para VimDiff , que muestra :
Invoque a Vimdiff como mergetool con git mergetool -t gvimdiff. Las versiones recientes de Git invocan a Vimdiff con el siguiente diseño de ventana:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL:
Un archivo temporal que contiene el contenido del archivo en la rama actual.BASE:
Un archivo temporal que contiene la base común para la fusión.REMOTE:
Un archivo temporal que contiene el contenido del archivo que se fusionará.MERGED:
El archivo que contiene los marcadores de conflicto.
Git ha realizado la mayor resolución de conflictos automática posible y el estado de este archivo es una combinación de ambos LOCALy REMOTEcon marcadores de conflicto que rodean todo lo que Git no pudo resolver por sí mismo.
El mergetooldebe escribir el resultado de la resolución a este archivo.
