Simuler une perte de commit et la réparer

Un commit peut disparaître de l’historique visible après un déplacement de branche, par exemple un git reset exécuté par erreur. Le travail n’est pas nécessairement perdu : si le commit figure encore dans le reflog local, vous pouvez le retrouver et le protéger avant qu’il ne devienne inaccessible.

Dans cette simulation, vous créez un commit non publié sur une branche de travail, vous déplacez volontairement cette branche en arrière, puis vous récupérez le commit. La procédure ne touche pas à la branche principale ni à l’historique partagé ; utilisez un dépôt de test ou une copie de travail propre.

Préparer un incident local maîtrisé

Commencez par vérifier que votre arbre de travail est propre et que vous êtes sur la branche attendue. Dans cet exemple, la branche s’appelle feature/guide-recuperation ; le commit simulé ajoute une note de procédure dans le fichier existant README.md. Cette modification ne change pas la structure du projet et ne crée aucun fichier supplémentaire.

git status --short --branch
git switch -c feature/guide-recuperation
printf '\nIncident simulé : procédure de récupération documentée.\n' >> README.md
git diff --check
git add README.md
git commit -m "docs: documenter la récupération locale"
git rev-parse --short HEAD

La dernière commande affiche le hash court du commit créé. Conservez-le pour vérifier que la récupération pointe vers le bon commit.

Notez le hash affiché et, si nécessaire, le résultat de git show --stat --oneline HEAD. Déplacez ensuite la branche d’un commit en arrière avec git reset --hard HEAD~1 : le commit disparaît alors de l’historique courant, et la ligne ajoutée à README.md n’est plus présente dans le fichier de travail. Cette commande détruit les modifications non enregistrées ; ne l’exécutez que dans cette simulation maîtrisée.

git reset --hard HEAD~1
git status --short --branch
git log -1 --oneline

La branche pointe maintenant sur le parent du commit de test. L’arbre de travail doit être propre ; le commit supprimé n’apparaît plus en tête de l’historique de la branche.

Retrouver et protéger le commit

Consultez les déplacements récents de HEAD et repérez l’entrée correspondant au commit dont le message est docs: documenter la récupération locale. Le reflog peut inclure plusieurs opérations proches ; ne choisissez pas un hash uniquement parce qu’il est le plus récent. Confirmez son message et son contenu avant de créer une branche de sauvegarde.

git reflog --date=local
git show --stat --oneline <hash-retrouve>
git show --format=fuller --no-ext-diff <hash-retrouve> -- README.md

Remplacez <hash-retrouve> par le hash de l’entrée correspondant au commit simulé. La sortie doit montrer le message attendu et uniquement le changement de documentation créé pour le test.

Une fois le hash vérifié, créez une branche qui pointe directement vers ce commit. Cette référence durable le rend visible dans les branches et facilite sa vérification, au lieu de laisser la récupération dépendre d’une entrée temporaire du reflog. Dans une réparation réelle, choisissez un nom descriptif qui respecte les conventions du dépôt ; ici, le nom est volontairement explicite.

git branch recuperation/guide-local <hash-retrouve>
git show --stat --oneline recuperation/guide-local
git diff --stat feature/guide-recuperation..recuperation/guide-local

La branche de récupération désigne le commit retrouvé. La comparaison montre le changement attendu entre la branche de travail déplacée et la référence restaurée.

Réintégrer le travail sans réécrire l’historique partagé

Pour restaurer la branche locale de travail, replacez-vous dessus et avancez-la jusqu’au commit récupéré. Dans cette simulation, le commit de base n’a pas avancé entre-temps : l’avance rapide suffit et conserve le commit original. Si d’autres commits ont été ajoutés entre-temps, arrêtez-vous et coordonnez la réparation avant de choisir une intégration adaptée ; ne remplacez pas l’historique d’une branche déjà partagée.

git switch feature/guide-recuperation
git merge --ff-only recuperation/guide-local
git log -2 --oneline
git show HEAD:README.md | tail -n 3
git status --short --branch

La branche avance jusqu’au commit récupéré sans créer de commit de fusion. Le message attendu et la ligne de documentation sont visibles, et l’arbre de travail est propre.

Comparez le hash de HEAD avec celui que vous aviez noté au début : il doit correspondre au commit retrouvé. Dans un incident réel, vous pouvez ensuite soumettre cette branche selon les règles habituelles de revue et de contrôles ; la branche de récupération reste une référence de secours jusqu’à ce que l’équipe ait confirmé la réparation. Les entrées du reflog ne remplacent ni une sauvegarde partagée ni la coordination avec les personnes concernées.

À retenir

• Simulez une perte uniquement dans un dépôt de test ou avec une branche locale et un arbre de travail propre.
• Repérez le commit dans le reflog, puis vérifiez son message, son hash et son contenu avant toute restauration.
• Créez une branche de récupération pour conserver une référence durable vers le commit retrouvé.
• Réintégrez le commit sur la branche locale sans réécrire l’historique partagé, puis contrôlez le contenu et l’état du dépôt.

Dans la prochaine leçon, vous validerez le flux complet de proposition de fusion à partir des conventions, des contrôles et des procédures de réparation établis.