Quand et comment faut-il réécrire l'historique Git ?

Question

Accepted Answer

Git vous permet de **réécrire l'historique** — en modifiant, en rebasant, en compressant ou en supprimant des commits — pour nettoyer les commits ou corriger des problèmes. C'est puissant mais doit être fait avec prudence : réécrire un historique **partagé** cause des problèmes sérieux, donc les règles autour de cela sont critiques. ## Façons de réécrire l'historique ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## La règle d'or ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## Utilisations légitimes de la réécriture (local) ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## Si vous devez réécrire l'historique partagé (rare) ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## Pourquoi c'est important Comprendre quand et comment réécrire l'historique Git est une connaissance importante au niveau senior car la réécriture d'historique est **puissante mais dangereuse**, et comprendre les règles — notamment autour de l'historique partagé — prévient les problèmes sérieux tout en permettant le nettoyage légitime. Connaître les **façons de réécrire** (amend pour le dernier commit, rebase interactif pour compresser/rédiger/réordonner, rebase pour un historique linéaire, reset, filter-repo pour les changements à grande échelle) et qu'elles **changent toutes les hashes des commits** (en créant de nouveaux commits) est la base. Most critiquement, comprendre la **règle d'or — ne jamais réécrire l'historique partagé/poussé** — est essentiel car réécrire change les hashes, ce qui fait diverger votre historique de celui des collaborateurs (qui ont toujours les anciens commits), entraînant des doublons, des conflits et une réconciliation douloureuse ; réécrire l'historique partagé est une perturbation sérieuse que cette règle prévient, avec **revert** (un nouveau commit d'annulation sûr) étant l'approche correcte pour les branches partagées à la place. Comprendre les **utilisations locales légitimes** (nettoyer les commits WIP avant une PR, corriger les erreurs avant de pousser, rebaser pour rester linéaire avant de partager — tout sur des commits locaux non poussés) clarifie quand la réécriture est appropriée et précieuse. Une nuance de sécurité cruciale : si un **secret a été committé et poussé**, réécrire l'historique pour le supprimer est insuffisant — le secret est déjà exposé et doit être **renouvelé** (un point de sécurité important du monde réel). Savoir comment **gérer la rare réécriture nécessaire de l'historique partagé** (coordination d'équipe, `--force-with-lease` plutôt que `--force`, tout le monde se resynchronisant) reflète un jugement mature. Comme la réécriture d'historique est puissante mais cause des problèmes sérieux quand elle est mal utilisée sur l'historique partagé, et comme comprendre la règle d'or, les utilisations légitimes et les pratiques sûres est essentiel pour l'utiliser de manière responsable, comprendre quand et comment réécrire l'historique Git est une connaissance importante au niveau senior — un sujet où comprendre les règles de sécurité (notamment ne jamais réécrire l'historique partagé) prévient les vrais désastres de collaboration, reflétant le jugement attendu pour les rôles senior travaillant avec Git en équipe.