Récupérer des données perdues dans Git

Vous avez supprimé une branche par erreur, fait un reset --hard de trop, ou perdu du travail en detached HEAD ? Git ne jette presque jamais rien. Le reflog conserve 90 jours d’historique local, et git fsck retrouve même les objets orphelins. Ce guide vous accompagne dans chaque scénario de récupération.

Prérequis : Sélection de révisions et HEAD détaché.

Ce que vous allez apprendre

• Utiliser le reflog pour retrouver tout commit ou état passé
• Récupérer une branche supprimée par erreur
• Récupérer des commits réalisés en HEAD détaché
• Annuler un reset --hard avant que le garbage collector n’intervienne
• Utiliser git fsck pour localiser des objets orphelins

Le reflog : votre machine à remonter le temps

Le reflog (reference log) enregistre chaque mouvement de HEAD dans votre repo local : commits, switches de branche, resets, rebases, checkouts…

git reflog

Sortie typique :

a1b2c3d HEAD@{0}: reset: moving to HEAD~3
e4f5a6b HEAD@{1}: commit: feat: authentification OAuth
c7d8e9f HEAD@{2}: commit: fix: corriger la pagination
b0a1c2d HEAD@{3}: commit: feat: page de profil
f1a2b3c HEAD@{4}: checkout: moving from feature/auth to main

Chaque ligne est un point de restauration. HEAD@{1} signifie « où HEAD était il y a 1 mouvement ».

Reflog avec horodatage

Pour voir les dates exactes :

git reflog --date=relative

a1b2c3d HEAD@{2 minutes ago}: reset: moving to HEAD~3
e4f5a6b HEAD@{5 minutes ago}: commit: feat: authentification OAuth

Le reflog avec --date=relative est utile quand vous ne savez plus quand vous avez fait l’erreur.

Récupérer après un reset —hard

Vous avez exécuté git reset --hard HEAD~3 par erreur et 3 commits ont disparu :

1. Consultez le reflog

   git reflog

   a1b2c3d HEAD@{0}: reset: moving to HEAD~3
   e4f5a6b HEAD@{1}: commit: feat: authentification OAuth

   La ligne HEAD@{1} montre le SHA du commit juste avant le reset.

2. Restaurez HEAD à la position d’avant le reset

   git reset --hard e4f5a6b

   Ou avec la notation reflog :

   git reset --hard HEAD@{1}

3. Vérifiez que les commits sont revenus

   git log --oneline -5

Les 3 commits sont de retour. Le reflog a permis de retrouver le SHA du commit perdu.

ORIG_HEAD : raccourci immédiat

Juste après un reset, merge ou rebase, Git stocke la position précédente dans ORIG_HEAD. Si vous réagissez immédiatement :

git reset --hard ORIG_HEAD

C’est plus rapide que de chercher dans le reflog, mais ne fonctionne que pour la dernière opération.

Récupérer une branche supprimée

Vous avez supprimé feature/dashboard avec git branch -D et réalisez que vous en aviez encore besoin :

1. Retrouvez le dernier commit de la branche dans le reflog

   git reflog

   Cherchez la ligne correspondant à la branche supprimée :

   f1a2b3c HEAD@{5}: commit: feat: ajouter les graphiques du dashboard
   d4e5f6a HEAD@{6}: commit: feat: layout du dashboard
   a7b8c9d HEAD@{7}: checkout: moving from main to feature/dashboard

   Le dernier commit de la branche est f1a2b3c.

2. Recréez la branche à partir de ce SHA

   git branch feature/dashboard f1a2b3c

3. Vérifiez que le contenu est complet

   git log --oneline feature/dashboard

La branche est restaurée avec tous ses commits.

Reflog d’une branche spécifique

Si vous connaissez le nom de la branche, consultez son reflog dédié :

git reflog show feature/dashboard

Cela montre uniquement les mouvements de cette branche, pas les mouvements de HEAD.

Sauver du travail en detached HEAD

Vous avez fait des commits en detached HEAD (par exemple après un git checkout <SHA> ou git switch --detach <SHA>) et vous voulez garder ce travail :

Symptôme

En quittant le detached HEAD, Git affiche un avertissement :

Warning: you are leaving 2 commits behind, not connected to
any of your branches:
  a1b2c3d feat: expérience WIP
  d4e5f6a fix: correction rapide

Solution : créer une branche avant de quitter

Si vous êtes encore en detached HEAD :

git switch -c rescue/mon-travail

Cela crée une branche qui capture tous vos commits.

Solution : récupérer après avoir quitté

Si vous avez déjà quitté le detached HEAD :

1. Retrouvez le SHA dans le reflog

   git reflog

   b0a1c2d HEAD@{0}: checkout: moving from a1b2c3d to main
   a1b2c3d HEAD@{1}: commit: feat: expérience WIP

2. Créez une branche sur ce SHA

   git branch rescue/mon-travail a1b2c3d

Délai limité

Les commits en detached HEAD non rattachés à une branche sont considérés comme « orphelins ». Par défaut, Git conserve leurs entrées de reflog 30 jours (gc.reflogExpireUnreachable), puis les objets sont purgés au prochain git gc (après 2 semaines supplémentaires, paramètre gc.pruneExpire). Récupérez-les rapidement.

Récupérer après un rebase raté

Un rebase qui a mal tourné peut être annulé :

Pendant le rebase

git rebase --abort

Revient à l’état exact d’avant le rebase — aucune modification perdue.

Après un rebase terminé

Le reflog montre l’état d’avant :

git reflog

a1b2c3d HEAD@{0}: rebase (finish): ...
f1a2b3c HEAD@{5}: rebase (start): checkout main
e4f5a6b HEAD@{6}: commit: mon dernier commit avant le rebase

Restaurez l’état d’avant :

git reset --hard HEAD@{6}

Ou utilisez ORIG_HEAD juste après :

git reset --hard ORIG_HEAD

Dernier recours : git fsck —lost-found

Si le reflog est vide (repo fraîchement cloné, reflog expiré après 90 jours), git fsck peut retrouver les objets orphelins :

git fsck --lost-found

Sortie :

dangling commit a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0
dangling commit d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0a1b2c3
dangling blob f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0

Examinez chaque commit orphelin :

git show a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

Si c’est le commit que vous cherchez, rattachez-le à une branche :

git branch rescue/found a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

Quand utiliser fsck vs reflog

Outil	Quand l’utiliser
git reflog	Premier réflexe — fonctionne dans 95% des cas
git fsck --lost-found	Reflog vide, repo cloné, expiration dépassée

Glissez pour voir

fsck est plus lent car il scanne tous les objets de la base de données Git. Le reflog est quasi instantané.

Récapitulatif des commandes de récupération

Situation	Commande
Retrouver un commit perdu	git reflog → noter le SHA
Annuler un reset —hard	git reset --hard HEAD@{N}
Annuler immédiatement (merge/reset/rebase)	git reset --hard ORIG_HEAD
Branche supprimée	git reflog → git branch nom SHA
Travail en detached HEAD	git switch -c rescue/nom (avant de quitter)
Travail perdu en detached HEAD	git reflog → git branch rescue/nom SHA
Rebase raté (en cours)	git rebase --abort
Rebase raté (terminé)	git reset --hard ORIG_HEAD
Reflog vide / expiré	git fsck --lost-found → git show SHA

Glissez pour voir

Dépannage : problèmes courants

Symptôme	Cause probable	Solution
Le reflog est vide	Repo fraîchement cloné (le reflog est local)	git fsck --lost-found
HEAD@{N} pointe vers le mauvais commit	Numérotation décalée par d’autres opérations	Utilisez le SHA directement, pas la notation HEAD@{N}
git branch dit que la branche existe déjà	La branche n’a pas été supprimée complètement	git switch nom-branche pour vérifier son contenu
fsck ne trouve rien	Le garbage collector a nettoyé les objets orphelins	Si le reflog a expiré (30 j, gc.reflogExpireUnreachable) et que git gc a tourné (pruneExpire = 2 semaines) : les données sont irrécupérables
ORIG_HEAD est incorrect	Plusieurs opérations depuis l’erreur	Utilisez le reflog avec un SHA précis

Glissez pour voir

À retenir

• Git ne jette presque jamais rien — les commits restent dans la base d’objets même après un reset ou une suppression de branche
• git reflog est votre premier réflexe : il montre chaque mouvement de HEAD des 90 derniers jours
• ORIG_HEAD est un raccourci pour annuler immédiatement la dernière opération (reset, merge, rebase)
• Branche supprimée : retrouvez le SHA dans le reflog et recréez la branche avec git branch nom SHA
• Detached HEAD : créez une branche (git switch -c) avant de quitter, ou retrouvez le SHA dans le reflog
• git fsck --lost-found est le dernier recours quand le reflog est vide
• Les entrées de reflog pour commits orphelins expirent après 30 jours (gc.reflogExpireUnreachable) ; les objets sont purgés au prochain git gc (délai gc.pruneExpire = 2 semaines par défaut) — agissez vite

Prochaines étapes

Diagnostiquer des problèmes Git Bisect, blame, log -S : trouvez l'origine d'un bug ou d'un changement.

Annuler et corriger des commits Amend, revert, reset : toutes les techniques d'annulation.

Reset démystifié Les 3 arbres de Git et les modes soft, mixed, hard en détail.

×

📖 Voir la documentation →