Git

Commit introuvable ? Le retrouver avec git reflog et créer une branche de secours

Utiliser le reflog local pour retrouver une ancienne référence, vérifier le commit et créer une branche de récupération sans réécrire l’historique.

Retrouver une référence avec le reflog, vérifier le commit puis créer une branche de secours sans réécrire l’historique.

Vous avez changé de branche ou déplacé HEAD et le commit recherché n’apparaît plus dans le parcours de git log que vous consultez ? Le reflog conserve localement des mises à jour récentes des références. Il peut aider à retrouver une ancienne valeur de HEAD puis à créer une branche de secours depuis le commit vérifié.

Inspecter le reflog du bon dépôt

Travaillez dans la copie locale qui a enregistré le déplacement recherché : un nouveau clone ne récupère pas le reflog de votre ancienne copie. Vérifiez la version de Git et l’état courant, puis lisez les entrées :

git --version
git status --short
git reflog -n 10 --date=local

Si le reflog est vide ou ne contient pas le déplacement, examinez éventuellement celui de la branche concernée avec git reflog show <nom-de-branche>. Des entrées expirées ou un objet supprimé ne peuvent pas être récupérés par cette procédure; conservez la copie disponible et recherchez une autre référence ou une sauvegarde. Évitez les opérations de purge pendant la recherche.

Fixer le hash du commit avant toute modification

Une entrée comme HEAD@{1} est un index relatif à l’état du reflog lors de la lecture. Toute opération qui déplace une référence peut changer les numéros. Après avoir repéré l’entrée pertinente, résolvez-la en hash complet :

git rev-parse --verify 'HEAD@{1}^{commit}'

Remplacez HEAD@{1} par l’entrée que vous avez réellement identifiée. Copiez le hash retourné et utilisez désormais cette valeur stable, représentée ci-dessous par <hash-confirmé>. Inspectez le commit, son message et ses changements :

git show <hash-confirmé>

Si le contenu ne correspond pas au travail recherché, reprenez la lecture du reflog avant de créer une référence. Si Git ne trouve pas l’objet, arrêtez cette récupération; le nom d’une entrée ne recrée pas un commit absent.

Créer une branche au nom libre et contrôler sa cible

Choisissez un nom de secours, ici recovery. Vérifiez qu’il n’existe pas déjà :

git show-ref --verify refs/heads/recovery

Si cette commande affiche une référence, choisissez un autre nom et recommencez le contrôle. Une référence absente entraîne un code non nul; ne confondez pas ce cas avec un dépôt inaccessible ou une autre erreur. Créez ensuite la branche avec le hash confirmé, sans option de remplacement forcé :

git branch recovery <hash-confirmé>
git rev-parse --verify 'recovery^{commit}'
git rev-parse --verify '<hash-confirmé>^{commit}'
git status --short

Remplacez le placeholder dans chaque commande et adaptez recovery si vous avez choisi un autre nom. Comparez les deux hashes complets : leur égalité signifie que la nouvelle branche désigne le commit inspecté. git branch crée cette référence sans changer de branche ni modifier les fichiers de travail; aucun reset n’est nécessaire pour préserver le commit. Pour consulter ensuite les fichiers de cette branche, décidez séparément d’un changement de branche en tenant compte de votre travail local.

Durée de conservation

Le reflog est local au dépôt et ses entrées peuvent expirer. La documentation Git indique des valeurs par défaut d’expiration de 90 jours pour les entrées de reflog et de 30 jours pour les entrées inaccessibles; la configuration du dépôt peut les modifier.

Sources techniques

  1. git-reflogGit SCM
  2. git-gcGit SCM
  3. git-branchGit SCM