Un parcours du tutoriel Récupérer des commits perdus : comment git reset --hard peut donner l'impression d'effacer un commit, et comment git reflog le retrouve pour que vous puissiez le restaurer.
Ce scénario enseigne le fait le plus rassurant de Git : un commit que vous avez « perdu » avec git reset --hard est presque toujours encore là. Vous allez voir le commit disparaître de l'historique, puis le ramener avec git reflog.
La situation
Le projet a trois commits : Initial commit, Add header navigation et Add skills section. Après un git reset --hard qui est allé une étape trop loin, le dernier commit n'apparaît plus dans git log. Il semble supprimé.
Il ne l'est pas. Le reset a déplacé le pointeur de branche en arrière, laissant le commit Add skills section en place mais non référencé. Git s'en souvient toujours.
git reset --hard écarte les modifications de travail et déplace la branche, ce qui le rend perçu comme destructeur. L'objet commit survit, mais le seul moyen facile d'y revenir passe par le reflog.
La récupération, étape par étape
Constater que le commit a disparu
git log
Le log se termine maintenant à Add header navigation. Le commit de compétences a disparu de cette vue, c'est le symptôme dont vous récupérez.
Le retrouver dans le reflog
git reflog
Le reflog liste tous les déplacements de HEAD, y compris le commit Add skills section avant le reset. Notez son hash (ou sa référence HEAD@{n}).
Ramener la branche sur ce commit
git reset --hard <hash-du-commit>
Faire pointer la branche sur le hash du commit perdu ramène Add skills section dans git log. L'historique est de nouveau complet.
Pourquoi le commit était récupérable
git log et git reflog répondent à des questions différentes :
git log montre les commits accessibles depuis la branche courante. Un reset retire le commit de cette chaîne, et il disparaît donc d'ici.git reflog montre partout où HEAD est passé, branche ou non. Le commit perdu y est toujours listé, avec le hash nécessaire pour y revenir.
Vous pouvez copier soit le hash brut, soit la référence de style HEAD@{1} depuis le reflog. Les deux fonctionnent avec git reset --hard.
Le reflog est local à votre clone. C'est un filet de sécurité personnel, non partagé avec le remote, donc toujours là pour vos propres erreurs.
Récupérer différents types de travail perdu
git reflog est le premier arrêt pour presque tous les moments « je l'ai perdu », car il enregistre chaque position tenue par HEAD :
- Après
git reset --hard — retrouvez le commit dans git reflog, puis git reset --hard <hash> pour y revenir (ou git checkout <hash> pour d'abord regarder).
- Une branche supprimée — son sommet est toujours dans le reflog ; recréez-la avec
git branch <name> <hash>.
- Un mauvais rebase ou amend — les commits d'avant le rebase sont dans le reflog ; réinitialisez sur l'entrée d'avant son exécution.
- Quand le reflog ne l'a plus — les entrées expirent (environ 90 jours par défaut, ou après un
git gc). git fsck --lost-found peut parfois encore faire remonter des commits orphelins.
Essayez ici : faites un commit, effacez-le avec reset --hard, puis ramenez-le depuis le reflog. Une fois que vous l'avez fait, reset --hard cesse de faire peur.