git fsck
Vérifier le dépôt et trouver les objets inaccessibles
La commande 'git fsck' (file system check) vérifie que chaque objet du dépôt est intact et que l’historique est entièrement relié. Elle signale aussi les objets orphelins (dangling) — des commits et fichiers vers lesquels plus rien ne pointe, comme un commit laissé par git reset --hard une fois que le reflog l’a oublié. On peut encore les récupérer tant que git gc ne les a pas supprimés.
Synopsis
git fsck [--unreachable] [--no-reflogs] [--lost-found] [--full] [<object>...]Options
Choisir la bonne option
Retrouver du travail perdu
Essayez d’abord le reflog
| Commande | Trouve |
|---|---|
git reflog | Partout où HEAD est passée (le plus simple) |
git fsck --no-reflogs | Les commits qu’aucune ref n’atteint |
git fsck --lost-found | Aussi les fichiers orphelins (p. ex. préparés puis perdus) |
Exemples
Vérifier
git fsckSilencieux quand tout va bien.
Trouver des commits perdus
git fsck --no-reflogsLes commits qu’aucune branche ni aucun tag n’atteint.
Les récupérer
git fsck --lost-foundLes copie dans .git/lost-found.
Exemples de workflows
git fsck --no-reflogsTrouver les commits orphelins
git show <hash>Le vérifier
git branch rescue <hash>Le garder
Dépannage
error: object file … is empty / corrupt
Cause : Dommage dû au disque ou à un plantage
Récupérez une copie neuve depuis le dépôt distant ; sauvegardez .git d’abord
Astuces et pièges
Bonnes pratiques
- ✓Lancez git fsck quand vous soupçonnez une corruption, avant git gc.
Erreurs fréquentes
- ✗Paniquer à cause d’objets « dangling » — ce sont des restes normaux, nettoyés par git gc.
FAQ
Un commit vers lequel rien ne pointe. Il est gardé jusqu’à ce que git gc le supprime (par défaut après l’expiration de l’entrée du reflog).