Le rebase interactif (git rebase -i) vous permet de réécrire, réorganiser, combiner, éditer ou supprimer des commits — en nettoyant votre historique de commits avant de le partager. C'est un outil puissant pour créer un historique propre et logique à partir de commits brouillons en cours de développement.
git rebase -i HEAD~4
git rebase -i <commit>
pick abc123 Add login form # keep the commit as-is
squash def456 Fix typo # COMBINE into the previous commit (merge messages)
fixup ghi789 Fix another typo # combine into previous, DISCARD this message
reword jkl012 Add validation # keep the commit but EDIT its message
edit mno345 Refactor auth # PAUSE to amend the commit (change content)
drop pqr678 Debug logging # DELETE this commit entirely
# reorder lines to REORDER commits
Vous éditez la liste — en choisissant une action par commit (et réorganiser les lignes réorganise les commits) — puis Git les rejoue en conséquence.
✓ SQUASH multiple WIP commits into one clean commit ("wip", "fix", "oops" → one good commit)
✓ REWORD bad commit messages
✓ REORDER commits into a logical sequence
✓ DROP unwanted commits (debug code, mistakes)
✓ SPLIT a commit (via edit) into smaller commits
→ Result: a clean, logical history instead of messy development commits.
⚠️ Interactive rebase REWRITES history (new commit hashes):
→ only do it on LOCAL, UNPUSHED commits — never on shared/public history
→ typical use: clean up your feature branch BEFORE pushing/opening a PR
Comprendre le rebase interactif est précieux pour créer un historique de commits propre, c'est donc une connaissance pratique utile pour le travail Git professionnel.
Pendant le développement, les commits sont souvent brouillons — commits en cours de travail avec des messages comme « wip », « fix typo », « oops », commits de debug, et un ordre non logique — et le rebase interactif vous permet de nettoyer cela avant de partager : fusionner plusieurs commits brouillons en commits logiques et propres, reformuler les mauvais messages, réorganiser les commits dans une séquence sensée, supprimer les commits indésirables (comme le code de debug), et scinder des commits — transformant l'historique brouillon du développement en une séquence propre, logique et révisable.
Cela importe parce qu'un historique de commits propre (comme couvert dans les bonnes pratiques de commits) rend la révision de code plus facile, l'historique plus compréhensible, et le débogage (via bisect) plus efficace — donc la capacité à nettoyer avant que d'autres voient votre travail est une caractéristique de la pratique Git professionnelle.
Comprendre les actions (pick, squash, fixup, reword, edit, drop, et réorganisation) et les utilisations courantes (notamment fusionner les commits WIP, un besoin très fréquent) est la compétence pratique.
De façon critique, la règle d'or du rebase s'applique toujours — le rebase interactif réécrit l'historique (nouveaux hashes), donc cela ne doit être fait que sur des commits locaux non poussés (jamais sur l'historique partagé), l'utilisation type étant le nettoyage d'une branche de fonctionnalité avant de la pousser ou d'ouvrir une pull request.
Puisqu'un historique de commits propre et logique est précieux pour la collaboration et la maintenabilité, et puisque le développement produit naturellement des commits brouillons que le rebase interactif peut nettoyer avant de partager (en toute sécurité, sur des commits locaux), comprendre le rebase interactif — les actions, les utilisations courantes comme la fusion, et la règle de sécurité — est une connaissance Git pratique et pertinente pour le développement professionnel, un outil puissant pour présenter un historique propre et révisable qui distingue les utilisateurs Git réfléchis, utilisé régulièrement pour polir le travail avant qu'il soit partagé avec l'équipe.