[Résumé] git reflog est la boîte noire de Git : il garde l’historique de tous les mouvements de HEAD, même après un reset ou un rebase raté. Grâce à lui, tu peux récupérer des commits “perdus”, restaurer une branche supprimée ou revenir à un état précédent. Rien n’est vraiment perdu tant que le reflog existe.
Il est 17h47, vous terminez enfin ce rebase un peu hasardeux sur votre branche “feature2”.
Tout semble en ordre… jusqu’à ce que Git vous affiche un message d’erreur, que votre code disparaisse, et que “git log” (ou l’arbre Git) ne montre plus que le vide.
Votre sang se glace : “J’ai tout perdu !”
C’est exactement le moment où la plupart des développeurs découvrent git reflog.
Cette commande, souvent méconnue, est pourtant la boîte noire de Git : elle garde une trace de tous les déplacements de votre curseur HEAD, même quand tout le reste semble avoir disparu. Aujourd’hui, on va comprendre pourquoi git reflog est votre meilleur allié, comment l’utiliser, et dans quelles situations il peut vous sauver une journée de travail.
Accrochez vos commits : on remonte le temps !
Quand tout semble perdu : comprendre le problème
Voici le scénario classique
- Vous avez fait un
git reset --hardpour “nettoyer un peu”. - Vous avez rebased une branche et tout s’est mélangé.
- Ou pire : vous avez supprimé une branche trop vite.
Dans chacun de ces cas, vos commits n’ont pas disparu immédiatement du dépôt, ils sont juste devenus orphelins : Git les a détachés de toute référence visible (branche, tag, etc..).
C’est là qu’intervient git reflog.
Tandis que git log montre les commits d’une branche, git reflog montre l’historique des mouvements de HEAD: chaque checkout, merge, rebase ou reset y est enregistré.
Qu’est-ce que “git reflog” exactement ?
Git conserve localement un petit journal appelé reflog (“reference log”).
Chaque fois que votre HEAD bouge – c’est-à-dire que vous changez de commit, de branche ou que vous réécrivez l’historique – Git enregistre l’événement.
En d’autres termes
git reflog, c’est un historique local des actions Git, même celles qui ne laissent plus de trace visible dans les branches.
A quel point est-ce différent de “git log” ?
| Commande | Ce qu’elle montre | Quand l’utiliser |
| git log | Les commits référencés dans la branche courante | Pour naviguer dans l’historique visible |
| git reflog | Tous les mouvements de HEAD (checkouts, resets, rebase, merge…) | Pour retrouver un état précédent, même effacé |
Lire et comprendre la sortie de “git reflog”
Voici un exemple réel, extrait d’un cas de “rebase” :
9233498 (HEAD -> feature2) HEAD@{0}: rebase (continue) (finish): returning to refs/heads/feature2
9233498 (HEAD -> feature2) HEAD@{1}: rebase (continue): Feature2 : deuxième commit
e0428e3 HEAD@{2}: rebase (continue): Feature2 : premier commit
4425e03 (develop) HEAD@{3}: rebase (start): checkout develop
cccca5c HEAD@{4}: checkout: moving from develop to feature2
4425e03 (develop) HEAD@{5}: commit: Develop : commit de hotfix
b025b0d HEAD@{6}: merge feature1: Merge made by the 'recursive' strategy.
31c76c7 (master) HEAD@{7}: checkout: moving from feature2 to develop
cccca5c HEAD@{8}: commit: Feature2 : deuxième commit
69a83e6 HEAD@{9}: commit: Feature2 : premier commit
31c76c7 (master) HEAD@{10}: checkout: moving from develop to feature2
31c76c7 (master) HEAD@{11}: checkout: moving from feature1 to develop
a7ac620 HEAD@{12}: commit: Feature1 : deuxième commit
d093062 HEAD@{13}: commit: Feature1 : premier commit
31c76c7 (master) HEAD@{14}: checkout: moving from develop to feature1
31c76c7 (master) HEAD@{15}: checkout: moving from master to develop
31c76c7 (master) HEAD@{16}: commit (initial): Commit initial
Chaque ligne du reflog contient :
- Le SHA du commit (exemple : 9233498)
- La position HEAD@{n} : un index chronologique, HEAD@{0} étant l’état actuel
- Une description de l’action (rebase, commit, checkout, merge, etc.)
- Un message associé (souvent le message du commit ou une mention de mouvement)
On voit bien ici que le reflog est une chronologie d’évènements permettant de remonter à n’importe quel état de votre dépôt local.
Scénario concret : autopsie d’un rebase
L’extrait précédent raconte un véritable film d’action Git :
1/ Le développeur a fait un premier commit sur la branche “master”
2/ Il a créé la branche “develop” et s’est positionné dessus
3/ Il a ensuite créé la branche “feature1” et s’est positionné dessus
4/ Il a fait deux commit sur la branche “feature1” (HEAD@{13} et {12})
5/ Après s’être repositionné sur la branche “develop”, il a créé la branche “feature2” et s’est positionné dessus (HEAD@{11} et {10})
6/ Là, il a ajouté deux commit (HEAD@{9} et {8}).
7/ Après s’être repositionné sur la branche “develop”, il a effectué un merge de la branche “feature1” sur “develop” (HEAD@{7} et {6}).
8/ Sur la branche “develop”, un nouveau commit de correctif est ajouté (HEAD@{5}).
9/ Après s’être repositionné sur la branche “feature2”, le développeur a lancé un rebase de la branche “feature2” sur la branche “develop” (HEAD@{4} et {0})
En lisant le reflog, on comprend exactement ce qui s’est passé dans le dépôt, même si git log ne montre plus qu’un historique aplati.
C’est le pouvoir du reflog : la vérité avant la réécriture.
Rétablir une version antérieure grâce à reflog
Revenir à un état précis
Supposons que vous vouliez revenir à l’état HEAD@{5} :
git reset --hard HEAD@{5}Git repositionne votre HEAD, votre index et votre workspace à ce moment exact.
Tous les fichiers reprennent l’état qu’ils avaient à ce moment-là.
Retrouver une branche supprimée
Vous avez supprimé la branche “feature2”, mais vous vous souvenez qu’elle pointait sur le commit d’identifiant “9233498” :
git branch feature2 9233498Et voilà, la branche renaît, exactement à l’endroit où elle avait été supprimée.
Annuler un rebase raté
Le rebase a tout cassé ?
Identifiez l’état avant le rebase (par exemple HEAD@{4} dans notre extrait), puis :
git reset --hard HEAD@{4}Vous revenez à la version stable avant la manœuvre.
Bon réflexe
Avant d’appliquer un reset, lancez toujours un git log --oneline (ou votre client graphique préféré pour afficher le graph git de votre dépôt) pour vérifier que vous revenez bien au bon endroit.
Ce qu’il faut retenir
git reflogest votre boîte noire : il garde tout ce que Git fait bouger.- Il permet de retrouver des commits perdus, des branches effacées, des états oubliés.
- C’est un outil local, propre à votre dépôt (chaque clone a son propre reflog).
- Il n’a aucune équivalence sur un dépôt distant (GitHub, GitLab, etc.).
- Et surtout : tant qu’il n’a pas été nettoyé, rien n’est vraiment perdu.
Conclusion
La prochaine fois qu’un rebase tourne mal, souvenez-vous : Git ne vous a pas trahi, il a tout gardé, sagement, dans un coin.
