Restaurer un commit devenu inaccessible

Vous avez retrouvé dans le reflog le hash d’un commit qui n’apparaît plus dans l’historique courant. Tant que vous n’avez créé aucune référence vers lui, il reste plus difficile à retrouver et peut finir par être supprimé. Vous allez lui donner un nom de branche durable, puis contrôler que ce nom désigne bien le commit attendu.

Choisir le commit à préserver

Dans la leçon précédente, vous avez appris à lire les déplacements de HEAD dans le reflog local. Reprenez le hash du commit recherché et vérifiez son identité avant de le nommer : un hash erroné peut préserver un état qui ne contient pas le travail attendu. Remplacez <hash-retrouve> dans les commandes suivantes par le hash complet ou abrégé que vous avez relevé.

git show --no-patch --format=fuller <hash-retrouve>
git show --stat --oneline <hash-retrouve>

Le premier affichage donne l’identifiant, l’auteur, la date et le message du commit. Le second résume les fichiers modifiés et les lignes concernées.

Ces commandes sont en lecture seule : elles n’altèrent ni le commit ni les fichiers de travail. Comparez le message et le résumé des changements à l’incident que vous cherchez à réparer. Si le contenu ne correspond pas, ne créez pas la branche à partir de ce hash ; reprenez les autres candidats du reflog et examinez-les de la même façon.

Créer une branche depuis le hash

Une branche Git est une référence nommée vers un commit. La commande git branch peut créer cette référence directement à partir d’un hash, sans déplacer la branche courante ni modifier le contenu de votre copie de travail. Choisissez un nom explicite qui indique qu’il s’agit d’une récupération ; ici, recuperation/commit-perdu désigne le commit retrouvé dans l’incident du dépôt.

git branch recuperation/commit-perdu <hash-retrouve>
git show --no-patch --format='%H %s' recuperation/commit-perdu
git log -1 --oneline recuperation/commit-perdu

Les deux dernières commandes affichent le commit associé à la branche, avec son hash et son message. Le hash affiché doit correspondre au commit vérifié à l’étape précédente.

Comprendre la durée de disponibilité

Le reflog n’est pas une archive permanente : il est local au dépôt et ses entrées expirent selon la configuration de Git. Les valeurs par défaut courantes conservent généralement plus longtemps les entrées associées à des objets encore atteignables que celles qui ne le sont plus ; les réglages du dépôt ou du système peuvent toutefois différer. Après expiration, un commit qui n’est plus référencé peut être supprimé par le nettoyage des objets Git.

La branche créée fournit désormais un nom stable dans ce dépôt local, même si l’entrée de reflog qui vous a permis de retrouver le commit disparaît ensuite. Contrôlez à nouveau son hash et son contenu avant toute opération ultérieure. La prochaine leçon traitera du choix entre annuler un commit partagé et réécrire l’historique d’une branche locale.

À retenir

• Vérifiez l’identité et le contenu du hash avant de créer une branche.
• Utilisez git branch pour nommer le commit retrouvé sans déplacer la branche courante.
• Confirmez le hash associé à la nouvelle branche avec git show ou git log.
• Le reflog est local et ses entrées peuvent expirer ; créez la référence dès que le commit recherché est identifié.