TL; DR (ajouté en mai 2018)

l'ensemble est fondamentalement au moins un peu confus parce que Git laisse son fonctionnement interne se montrer à vous.

notez que les cas qui nous intéressent ici se produisent lorsque vous exécutez:

git checkout somebranch; git rebase origin/their-branch

ou similaire. Le rebase s'est arrêté temporairement pour vous forcer à résoudre un conflit de fusion, après quoi vous êtes censé git add le conflit résolu et Lancez git rebase --continue . (Si vous utilisez un outil de fusion avec git mergetool , ou une interface graphique de fantaisie, cette interface peut faire une partie ou tout cela pour vous d'une autre manière, mais en dessous, c'est git add ing les fichiers résolus et l'exécution git rebase --continue .)

au tout début, le HEAD commit est leur branche, de sorte que si vous utilisez git checkout --ours ou git checkout --theirs , --ours signifie la leur - la Commission finale de origin/their-branch - alors que --theirs signifie votre , le premier commit que vous rebasez. Il s'agit de la confusion habituelle de Git (voir ). Quelle est la signification précise de "Notre" et "la leur" dans git? ) et n'est pas ce qui a conduit à la question initiale.

plus tard, cependant, le HEAD commit est en fait une sorte de mélange . C'est le résultat de copier un certain nombre de votre commits atop leur dernier commit . Vous obtenez maintenant un conflit entre votre propre partiellement construit "nouvelle série de commits, et votre propre originale commits. La source de ce conflit est habituellement quelque chose "qu'ils" ont fait (quelque chose qui a changé en cours de route dans origin/their-branch ). Vous avez encore à résoudre ce conflit. Lorsque vous le faites, vous pouvez voir le même conflit se reproduire plus tard s'engage.

de nouveau, HEAD ou local ou --ours est un commit que rebase a construit en combinant vos modifications et leurs changements , et l'autre commit ( remote ou >>>>>>> ou --theirs ) est votre propre commit, que rebase essaie de copier au-dessus de HEAD .

Plus

lors de la fusion (y compris le rebasement, qui est un cas particulier de "fusion" répétée en interne), il y a deux "les chefs" (deux branche spécifique-conseils). Appelons-les your-branch et origin/their-branch :

              G - H --------      <-- HEAD=your-branch
            /               \
... - E - F                   M   <-- desired merge commit [requires manual merge]
            \               /
              I - J - K - L       <-- origin/their-branch

ce point est souvent (et sans surprise) confus, bien que quand étiqueté comme ceci il est assez clair.

ce qui le rend pire, bien que git utilise --ours et --theirs pour se référer aux deux têtes commet pendant une fusion, avec "notre" étant celui que vous étiez sur (commit H ) quand vous avez couru git merge , et " leurs" être, bien, le leur (commit L ). Mais quand vous faites un rebase, les deux têtes sont inversées, de sorte que "la nôtre" est la tête que vous rebasez sur-c'est-à-dire leur code mis à jour-et "la leur" est la propagation que vous rebasez actuellement, c'est-à-dire votre propre code.

c'est parce que rebase utilise en fait une série d'opérations de cueillette. Vous commencez avec à peu près la même image:

              G - H           <-- HEAD=your-branch
            /
... - E - F
            \
              I - J - K - L   <-- origin/their-branch

ce que git doit faire ici est de copy l'effet de commits G et H , c'est à dire, git cherry-pick commit G , puis faire à nouveau avec le commettre H . Mais pour ce faire, git doit switch to commit L first, internally (using" detached HEAD "mode):

              G - H           <-- your-branch
            /
... - E - F
            \
              I - J - K - L   <-- HEAD, origin/their-branch

maintenant il peut commencer l'opération de rebase en comparant les arbres pour commits F et G (pour voir ce que vous avez changé), puis comparer F vs L (pour voir si une partie de votre travail est déjà dans L ) et en prenant n'importe quels changements pas déjà dans L et l'ajouter. Il s'agit d'une opération de" fusion " interne.

              G - H           <-- your-branch
            /
... - E - F                   G'   <-- HEAD
            \               /
              I - J - K - L   <-- origin/their-branch

si la fusion ne se passe pas bien, HEAD reste à commit L (car commit G' n'existe pas encore). Ainsi, Oui, HEAD est le chef de leur branche de développement-du moins, il est maintenant.

une fois que la copie de G existe, bien que, HEAD se déplace à G' et git tente de copier les changements de H , de la même manière (diff G vs H , puis diff F vs G' , et fusionner les résultats):

              G - H           <-- your-branch
            /
... - E - F                   G' - H'   <-- HEAD
            \               /
              I - J - K - L   <-- origin/their-branch

encore une fois, si la fusion échoue et a besoin d'aide, vous êtes laissé avec HEAD pointant vers G' au lieu de H' comme H' n'existe pas encore.

une fois que les fusions tout réussir et commet G' et H' do existent, git supprime l'étiquette your-branch de commit H , et le fait de commit H' à la place:

              G - H
            /
... - E - F                   G' - H'   <-- HEAD=your-branch
            \               /
              I - J - K - L   <-- origin/their-branch

et vous êtes maintenant relocalisée et HEAD est une fois de plus ce que vous attendez. Mais pendant le rebase, HEAD est soit leur branche-pointe (commit L ), soit l'un des nouveaux --ours signifie la branche étant cultivée à la fin de L tandis que --theirs signifie la propagation étant copiée-de ( G ou H ci-dessus).

(c'est essentiellement git exposer le mécanisme brut de comment il fait ce qu'il fait, ce qui se produit plutôt beaucoup dans git.)