Git : récupérer un commit perdu après un reset ou un rebase

Le reflog peut retrouver un commit après un reset ou un rebase. Travaillez dans le clone où l’opération a eu lieu : le reflog reste local.

Préserver la situation actuelle

git status
git branch sauvegarde-etat-actuel

La branche sert de repère vers le commit actuel. Elle ne sauvegarde pas les fichiers modifiés ou non suivis : copiez ceux qui comptent hors du dépôt, ou enregistrez-les avant de changer de branche.

Si un rebase est encore en cours et que vous souhaitez simplement revenir à son point de départ, utilisez git rebase --abort. Cela abandonne aussi les résolutions effectuées pendant ce rebase : conservez-les d’abord si nécessaire.

Évitez le nettoyage du dépôt, notamment git gc --prune=now, tant que la récupération n’est pas terminée.

Retrouver le bon commit

git reflog --date=iso -30

Repérez les lignes reset, rebase ou commit autour du moment où le travail a disparu. Si le résultat est insuffisant, élargissez la recherche :

git reflog show --all --date=iso

Copiez l’identifiant candidat à la place de SHA_RETROUVE, puis examinez-le :

git show --stat SHA_RETROUVE
git show SHA_RETROUVE

Ne choisissez pas automatiquement « la ligne précédente » : un rebase peut produire plusieurs déplacements. Vérifiez le message et les fichiers. Préférez l’identifiant du commit à HEAD@{1}, dont la signification change au fil des opérations.

Mettre le commit à l’abri

git branch recuperation-travail SHA_RETROUVE
git log -5 --oneline recuperation-travail

Cette commande ne change pas vos fichiers ni la branche active. Elle crée une référence durable vers le commit et ses ancêtres. Choisissez un nom libre si recuperation-travail existe déjà.

Pour reprendre directement ce travail, une fois vos changements locaux sauvegardés :

git switch recuperation-travail

Récupérer seulement ce qui manque

Si votre branche actuelle contient déjà des corrections à conserver, restez sur cette branche et choisissez une des méthodes suivantes.

Pour récupérer les changements d’un commit ordinaire :

git cherry-pick SHA_RETROUVE

Un cherry-pick reprend un seul commit, pas automatiquement toute la branche. S’il manque plusieurs commits, examinez leur ordre et leurs dépendances avant de les reprendre. Un commit de fusion nécessite un traitement spécifique.

En cas de conflit, corrigez les fichiers, ajoutez-les avec git add, puis lancez git cherry-pick --continue. Pour abandonner l’opération en cours : git cherry-pick --abort.

Pour récupérer seulement la version d’un fichier :

git restore --source=recuperation-travail -- chemin/du/fichier
git diff -- chemin/du/fichier

Cette restauration remplace le contenu local de ce fichier. Sauvegardez sa version actuelle si elle contient du travail utile, puis commitez la version récupérée après relecture.

Si le reflog ne contient rien

Vérifiez les autres clones, les branches distantes et les commits associés aux pull requests. En dernier recours, git fsck --full --no-reflogs --unreachable peut signaler des commits encore présents sans référence ; inspectez chaque candidat avec git show.

La récupération n’est pas garantie : les reflogs expirent et Git peut supprimer les objets devenus inaccessibles. Un fichier jamais ajouté ni commité n’est pas récupérable par le reflog ; cherchez plutôt dans l’historique local de l’éditeur ou vos sauvegardes.

Vérifier la récupération

Contrôlez git status, l’historique et les fichiers attendus, puis lancez les tests du projet. Gardez la branche de récupération jusqu’à avoir confirmé que tout le travail utile est présent.