TL, DR;
Pour résumer (comme le commente Benubird ), quand:
git checkout A
git rebase B # rebase A on top of B
localest B(rebase sur ),remote est A
Et:
git checkout A
git merge B # merge B into A
localest A(fusionner dans ),remote est B
Un rebase bascule ours(branche actuelle avant le début du rebase) et theirs(la branche au-dessus de laquelle vous voulez rebase).
kutschkem souligne que, dans un contexte de mergetool d'interface graphique :
- local fait référence aux commits partiellement rebasés : "
ours" (la branche amont)
- remote fait référence aux modifications entrantes : "
theirs" - la branche actuelle avant le rebase.
Voir les illustrations dans la dernière partie de cette réponse.
Inversion lors du rebase
La confusion pourrait être liée à l' inversion de ourset theirspendant un rebase .
(extraits pertinents)
git rebasepage de manuel :
Notez qu'une fusion de rebase fonctionne en rejouant chaque commit à partir de la branche de travail au-dessus de la <upstream>branche.
Pour cette raison, lorsqu'un conflit de fusion se produit:
- le côté signalé comme `
ours` est la série rebasée jusqu'à présent, commençant par <upstream>,
- et '
theirs' est la branche active. En d'autres termes, les côtés sont échangés.
Inversion illustrée
Sur une fusion
x--x--x--x--x(*) <- current branch B ('*'=HEAD)
\
\
\--y--y--y <- other branch to merge
, nous ne changeons pas la branche actuelle 'B', donc ce que nous avons est toujours ce sur quoi nous travaillions (et nous fusionnons depuis une autre branche)
x--x--x--x--x---------o(*) MERGE, still on branch B
\ ^ /
\ ours /
\ /
--y--y--y--/
^
their
Sur un rebase:
Mais sur un rebase , on change de côté car la première chose qu'un rebase fait est de vérifier la branche amont! (pour rejouer les commits actuels dessus)
x--x--x--x--x(*) <- current branch B
\
\
\--y--y--y <- upstream branch
A git rebase upstreampassera d'abord HEADde B à la branche amont HEAD(d'où le changement de «le nôtre» et «le leur» par rapport à la branche de travail «actuelle» précédente).
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
, puis le rebase rejouera 'leurs' commits sur la nouvelle branche B 'notre':
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
Remarque: la notion «amont» est l'ensemble référentiel de données (un tout repo ou, comme ici, une branche, qui peut être une branche locale ) à partir duquel les données sont lues ou auxquelles de nouvelles données sont ajoutées / créées.
' local' et ' remote' contre ' mine' et ' theirs'
Pandawood ajoute dans les commentaires :
Pour moi, la question demeure, qui est "local" et qui est "distant" (puisque les termes "nôtre" et "leur" ne sont pas utilisés lors du rebasage dans git, y faire référence semble juste rendre la réponse plus confuse) .
GUI git mergetool
kutschkem ajoute, et à juste titre:
Lors de la résolution des conflits, git dira quelque chose comme:
local: modified file and remote: modified file.
Je suis tout à fait sûr que la question vise à définir à ce stade le terme local et distant. À ce stade, il me semble d'après mon expérience que:
- local fait référence aux commits partiellement rebasés : "
ours" (la branche amont)
- remote fait référence aux modifications entrantes : "
theirs" - la branche actuelle avant le rebase.
git mergetoolmentionne en effet «local» et «distant» :
Merging:
f.txt
Normal merge conflict for 'f.txt':
{local}: modified file
{remote}: modified file
Hit return to start merge resolution tool (kdiff3):
Par exemple, KDiff3 serait afficher la résolution de fusion comme ceci :
Et meld l' afficherait aussi :
Idem pour VimDiff , qui affiche :
Appelez Vimdiff en tant qu'outil de fusion avec git mergetool -t gvimdiff. Les versions récentes de Git invoquent Vimdiff avec la disposition de fenêtre suivante:
+--------------------------------+
| LOCAL | BASE | REMOTE |
+--------------------------------+
| MERGED |
+--------------------------------+
LOCAL:
Un fichier temporaire contenant le contenu du fichier sur la branche courante.BASE:
Un fichier temporaire contenant la base commune pour la fusion.REMOTE:
Un fichier temporaire contenant le contenu du fichier à fusionner.MERGED:
Le fichier contenant les marqueurs de conflit.
Git a effectué autant de résolution automatique des conflits que possible et l'état de ce fichier est une combinaison des deux LOCALet REMOTEavec des marqueurs de conflit entourant tout ce que Git n'a pas pu résoudre lui-même.
Le mergetooldoit écrire le résultat de la résolution dans ce fichier.
