Que signifie `git rebase --fork-point master` ?

Question

Mon cas d'utilisation est le suivant changer mes commits dans une branche de fonctionnalité avant de la publier, par exemple, reformuler les messages de commit, écraser certains commits, etc. Je ne veux pas déplacer les commits vers une nouvelle base.

Pour cela, je fais habituellement quelque chose comme ça :

git rebase -i HEAD~4

où le nombre "4" est le résultat du comptage manuel des commits dans ma branche de fonctionnalité.

Je me demandais si Git dispose d'une commande telle que "Lancer un rebasement interactif pour tous les commits de ma branche de fonctionnalité mais ne pas les déplacer vers une branche plus récente. master - reste juste où tu es" . J'ai trouvé le --fork-point option de git rebase et j'ai essayé ça :

git rebase -i --fork-point master

Cependant, cela n'a pas d'effet notable et se comporte de la même manière que le programme git rebase -i master .

Au lieu de cela, ceci fait ce dont j'ai besoin :

git rebase -i $(git merge-base --fork-point master)

J'ai lu les docs de --fork-point en git rebase mais je ne comprends pas bien pourquoi cela n'a pas abouti au résultat escompté. Quelqu'un peut-il m'expliquer ?

Answer 1

Cela n'a pas mené au résultat escompté parce que --fork-point n'a rien à voir avec le choix de la base pour les nouveaux commits[1].

Donc, par défaut, les nouveaux commits sont basés sur les commits amont ( master dans ce cas), et --fork-point n'a pas d'incidence.

(Pour référence, ce que --fork-point c'est-à-dire qu'il utilise les reflogs pour affiner le calcul qui "devine" quels commits doivent être réécrits. Ce n'est pas toujours - ou même, d'après mon expérience, pas toujours - le cas. souvent - très utile).

Vos deux options sont d'utiliser la base de fusion comme amont - comme vous le décrivez - ou d'utiliser la fonction --onto pour définir explicitement la nouvelle base (dans ce cas, en la faisant correspondre à la base originale).

---

[1] - rappelez-vous que même si conceptuellement vous éditez des commits, en réalité rebase écrit toujours de nouveaux commits - sauf quand il ne fait rien. Ainsi, lorsqu'il " édite " un commit, il crée en réalité de nouveaux commits qui sont similaires aux anciens commits, mais édités.

Answer 2

Je m'attends à ce que l'invocation plus simple ci-dessous fasse ce dont vous avez besoin.

git rebase -i $(git merge-base HEAD master)

La documentation pour git merge-base --fork-point montre que l'option peut être très utile, mais dans le contexte d'une histoire compliquée. Votre question n'indique pas que vous avez beaucoup réécrit l'histoire, donc --fork-point peut être excessif pour votre cas.

Discussion sur le mode fourchette

Après avoir travaillé sur la branche du sujet créée avec

git switch -c topic origin/master

l'histoire de la branche téléguidée origin/master a pu être rembobiné et reconstruit, ce qui a conduit à une histoire de cette forme :

                 o---B2
                /
---o---o---B1--o---o---o---B (origin/master)
        \
         B0
          \
           D0---D1---D (topic)

donde origin/master utilisé pour pointer vers les commits B0 , B1 , B2 et maintenant, il pointe vers B et la branche de votre sujet a été créée par-dessus. quand origin/master était à B0 et vous avez construit trois commits, D0 , D1 y D par-dessus. Imaginez que vous voulez maintenant refaire le travail que vous avez fait sur le sujet au-dessus de la mise à jour origin/master .

Dans un tel cas, git merge-base origin/master topic retournerait le parent de B0 dans l'image ci-dessus, mais B0^..D n'est pas la portée de que vous voudriez rejouer au dessus de B (il comprend B0 , ce qui n'est pas ce que vous avez écrit ; c'est un engagement que l'autre côté a rejeté lorsqu'elle a déplacé sa pointe de B0 a B1 ).

git merge-base --fork-point origin/master topic est conçu pour aider dans un tel cas. Il prend en compte non seulement B mais aussi B0, B1, et B2 (c'est-à-dire les anciennes pointes des branches de suivi à distance que le reflog de votre dépôt connaît) pour voir sur quel commit la branche de votre sujet a été construite et trouve B0, ce qui vous permet de rejouer uniquement les commits sur votre sujet, en excluant les commits que l'autre partie a ensuite écartés.

Le site git rebase --fork-point documentation fait le lien entre git rebase --fork-point y git merge-base --fork-point .

Lorsque --fork-point est actif, point de bifurcation sera utilisé à la place de en amont pour calculer l'ensemble des commits à rebaser, où point de bifurcation est le résultat de

git merge-base --fork-point <upstream> <branch>

commande. (Voir git-merge-base .)

Answer 3

Git 2.24 introduira une nouvelle option , --keep-base :

"git rebase --keep-base" essaye de trouver la base originale du sujet en cours de rebasement et de rebasement par dessus cette même base, ce qui est utile lors de l'exécution de la commande "git rebase -i" (et sa variante limitée variante limitée "git rebase -x").

Il semble que cela pourrait être la solution au cas d'utilisation du PO, mais je n'ai pas encore essayé.