Git merge vs rebase : le commit a-t-il quitté votre machine ?

■ space · chronique

LES DEUX HISTORIQUES

Les deux commandes posent le même code ; elles se disputent sur ce que l'historique doit raconter ensuite. J'ai lancé les deux dans un banc jetable sous git 2.47.3, mêmes cinq commits à chaque fois — le passage merge a gardé chaque SHA d'origine et ajouté un nœud ; le passage rebase a changé l'identité des commits de la branche. Même arbre, historique différent :

fig — les primes sont les mêmes changements avec de nouveaux IDs de commit : c3 est entré en 5d48940 et est ressorti en 6b2be0a

vérif : git log --oneline --graph → a "|\\\\" désigne un merge, une ligne droite signifie que le rebase a gagné

QUAND LE MERGE DEVIENT UN FAST-FORWARD

Si main n'a pas bougé depuis la création de votre branche, il n'y a rien à merger — git fait juste glisser l'étiquette vers l'avant. C'est un fast-forward, et c'est pourquoi les partisans du rebase obtiennent leur belle ligne sans rien forcer : rebasez votre branche sur main, puis le merge devient un fast-forward, et le graphe reste une seule ligne droite. Depuis le banc — cinq commits, zéro nœud :

* 67c0442 c4 feature 2      # rebased, then merged — fast-forward
* 6b2be0a c3 feature 1      # new SHAs — 5d48940 before the rebase
* 1398836 c5 main moved on
* facd5a4 c2 main work
* f45b000 c1 base

vérif : git merge --ff-only feature → "Fast-forward" dans la sortie, aucun commit de merge créé

La contrepartie : ces SHAs primes n'existent plus nulle part sauf sur votre machine. Poussez-les et le clone d'un collègue garde toujours les originaux — deux versions du « même » commit.

QUELS COMMITS SONT ENCORE À VOUS SEUL ?

La réponse tient en une commande, pas dans une intuition. git log origin/main..HEAD liste les commits que l'origine n'a jamais vus — ceux-là sont rebasables. Si la liste contient un commit qu'un autre clone peut déjà avoir — un push, une pull request ouverte, une branche que vous avez poussée puis forcée par le passé — il n'est pas à vous seul, quoi qu'affirme votre graphe local. Le travail non poussé est exactement ce pour quoi le rebase existe : rejouez-le sur la base à jour et votre pull request se lit comme une seule séquence propre. C'est aussi pourquoi git pull --rebase est un défaut raisonnable pour les branches privées — il rejoue vos commits locaux sur ce qui est arrivé, au lieu de tisser un nœud de merge à chaque synchro. Fiez-vous à la branche, pas au flair : git fetch origin d'abord, git status -sb pour le couple en avance/en retard.

CE QUI CASSE SUR UNE BRANCHE PARTAGÉE

Tout clone qui détient les anciens commits est désormais en désaccord avec le vôtre sur la réalité. Le rebase donne à vos commits de nouveaux SHAs ; votre branche poussée et votre branche réécrite n'ont plus d'ancêtre commun, donc le prochain push exige --force — et tous ceux qui ont tiré l'ancienne version doivent merger leur copie de commits qui « n'existent plus ». Leurs doublons refont surface dans chaque merge futur ; les démêler coûte un après-midi. Les commentaires de relecture accrochés à des SHAs précis se détachent dans le même mouvement — rebasez une pull request ouverte et le contexte de la relecture s'évapore avec les anciens IDs de commit. La règle tient en une phrase, et le livre officiel la porte comme un avertissement, pas une suggestion :

Ne rebasez pas des commits qui existent hors de votre dépôt et sur lesquels des personnes ont pu bâtir leur travail.— Pro Git, 2e édition, « Git Branching — Rebasing »

ANNULER UN REBASE

Les anciens commits survivent au rebase — le reflog est leur cachette. Le rebase déplace des pointeurs de branche ; il ne supprime pas d'objets. La récupération du banc, après qu'un reset --hard a jeté deux commits :

$ git reflog | head -4
1398836 HEAD@{0}: reset: moving to HEAD~2
67c0442 HEAD@{1}: merge feature: Fast-forward
1398836 HEAD@{2}: checkout: moving from feature to main
67c0442 HEAD@{3}: rebase (finish): returning to refs/heads/feature

$ git reset --hard HEAD@{1}
HEAD is now at 67c0442 c4 feature 2

Une ligne, branche restaurée, travail indexé et non indexé avec elle. Les entrées de reflog expirent après environ 90 jours par défaut, donc le sauvetage a un chronomètre.

vérif : git reflog | head -3 → la pointe d'avant-rebase est à HEAD@{1}, à un reset de là

LES SIX SITUATIONS

Où place-t-on --squash ? Il prend les changements d'une branche et les indexe en un seul tas non commité — pas de commit de merge, aucun lien avec l'historique de la branche. Le squash est la troisième réponse, pour jeter une branche après avoir atterri son changement net ; il ne réécrit rien, il refuse simplement d'enregistrer les étapes internes de la branche. Et une équipe peut-elle choisir une seule voie ? Beaucoup le font : rebase pour le travail local, merge vers le partagé est la politique la plus courante, et un « rebase tout » à l'échelle du dépôt marche aussi — tant qu'aucune branche partagée n'est jamais réécrite, la seule phrase qui survit à chaque débat de workflow. La version dix secondes, une dernière fois : le commit a-t-il quitté votre machine ? Non → rebase. Oui → merge. Quand le mauvais gagne quand même, le reflog garde la sortie.

fin des deux historiques · rien de tiré · tout est local