CaenHackYouAcademy
Git

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 garder

Cinq 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.

VérificationQuestion 1 / 3

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 ]

On this page