Réécrire l'histoire
amend, rebase, rebase interactif — et la seule règle qui compte.
Aucune commande de Git ne modifie un commit. C'est structurellement impossible :
l'identifiant est l'empreinte du contenu. Ce que font amend et rebase,
c'est créer de nouveaux commits et déplacer les pointeurs — les anciens
deviennent injoignables.
Retenir cela évite la plupart des paniques : rien n'a été détruit, des pointeurs ont bougé.
Corriger le dernier commit
git commit --amend # message et/ou contenu
git commit --amend --no-edit # contenu seulement, message conservéLe commit obtenu a une empreinte différente : c'est un remplacement, pas une retouche. Parfait tant que le commit d'origine n'a pas été poussé.
Rebase : rejouer ailleurs
avant : A───B───C (main)
\
D───E (fonction)
après : A───B───C (main)
\
D'──E' (fonction)D' et E' sont de nouveaux commits : même contenu, même message, parents
différents, donc empreintes différentes. L'historique devient linéaire, comme si
le travail avait commencé après C.
C'est l'intérêt : une branche rebasée avant sa fusion produit un historique lisible, sans entrelacement. Et c'est aussi le danger, dès qu'elle est partagée.
Le rebase interactif
$ git rebase -i main
pick a1b2c3d Ajoute le chargement des quiz
squash e4f5g6h Corrige une faute de frappe
squash i7j8k9l Corrige encore
reword m0n1o2p Ajoute la correction serveur
drop q3r4s5t Test temporaire, à ne pas garderCinq verbes suffisent au quotidien : pick garde, squash fusionne dans le
précédent, reword change le message, edit s'arrête pour modifier, drop
supprime. C'est l'outil qui transforme huit commits de tâtonnement en trois
commits qui racontent une décision.
La règle d'or
Ne jamais réécrire un historique que d'autres ont récupéré. Sur ta branche
personnelle, non poussée ou poussée mais que personne d'autre n'utilise, réécris
autant que tu veux : c'est même la bonne pratique avant une demande de fusion.
Sur main, ou sur une branche à plusieurs, la réécriture fait diverger le dépôt
de chacun — leur prochain pull produit des doublons ou un conflit
incompréhensible, et quelqu'un finit par réintroduire les anciens commits.
Le piège classique
git pull --rebase réécrit tes commits locaux pour les poser après ceux du
serveur. C'est sans danger, puisqu'il ne touche que ce que tu n'as pas encore
publié — et c'est ce qui évite les commits de fusion parasites qui polluent
l'historique d'une équipe.
En revanche, un rebase interrompu par un conflit se termine par
git rebase --continue, jamais par un commit. Et git rebase --abort restaure
l'état d'avant, intégralement : c'est la sortie de secours à connaître avant de
commencer.
Réponse unique
Que fait réellement un rebase aux commits déplacés ?
Indice · L'empreinte dépend du parent.
[ METTRE EN PRATIQUE ]
Nettoyer une branche avant la fusion
3 étapes · 30 min · 130 XP
[ CETTE LEÇON DANS LES PARCOURS ]
- Fondamentauxétape 6 / 18suivant — Réparer →