Trouver un commit perdu avec reflog

• Lisez le reflog comme l'enregistrement de ce référentiel indiquant où se trouvaient HEAD et les branches.
• Vérifiez le contenu d'un commit candidat avant de le récupérer.
• Créez une branche au niveau du commit mesuré sans l'extraire.
• Dites ce que le reflog ne peut pas rapporter : des travaux non validés et des entrées expirées.

Vous êtes sur private/lost-signup, une branche du résultat M de la leçon 18. Vous avez validé une note, "docs : conservez la note de récupération d'inscription", qui a ajouté docs/signup-recovery.md, puis avez exécuté une réinitialisation matérielle avec une validation. La note a disparu de la branche, du graphique et de vos fichiers. Vous n'avez pas encore de branche de secours et vous n'avez rien changé d'autre.

Tout est local et sur le forfait gratuit (GitTree vous demande de vous connecter) : pas de compte d'hébergement, pas de fournisseur, pas d'Internet. Chaque identité est fictive (exemple.com). N'exécutez jamais cette leçon dans un projet réel. La réinitialisation matérielle dans la préparation est une répétition dans une copie jetable.

Apportez les modifications dans GitTree ou avec les commandes Git natives, pas les deux dans la même copie. La lecture du résultat est toujours sûre. Les étiquettes de menu proviennent des propres chaînes de GitTree 2.0 et les commandes natives ont été exécutées avec Git 2.43 dans des copies jetables. Les étapes GitTree n'ont pas été exécutées le macOS, Windows ou Linux.

Le reflog est un journal local des mouvements des arbitres. HEAD en a un, tout comme chaque branche. Il enregistre "commit", "checkout", "reset" et autres, avec le commit sur lequel chacun a atterri. Un autre clone n'a pas votre journal. Un commit selon lequel aucun nom de branche ne peut encore exister, et le reflog est la façon dont vous le trouvez.

Les sélecteurs tels que HEAD@{1} comptent les entrées à partir de maintenant, ils changent donc à chaque opération ultérieure. Lisez l'action, l'heure, la pièce d'identité et le dossier d'un candidat avant de l'utiliser. Ne mémorisez pas un décalage comme une recette.

Le reflog trouve les commits qui ont été enregistrés. Il ne peut pas trouver une modification qui n'a jamais été validée, comme l'a montré la leçon 27. Les entrées expirent : par défaut, Git conserve les entrées pour les validations qu'aucune branche n'atteint pendant environ trente jours, et un référentiel peut modifier cela. N'exécutez pas de commandes de nettoyage ou d'expiration pendant la récupération.

La création d'une branche au niveau du commit ajoute une référence et rien d'autre. La branche actuelle, l'index et vos fichiers restent là où ils se trouvent.

Commencez par une copie ordinaire séparée du résultat M de la leçon 18 et laissez votre original intact. Créez la branche, enregistrez DOC_LOST, validez-la et réinitialisez matériellement une validation. Cette préparation destructrice est destinée à une copie jetable uniquement.

Enregistrez uniquement à la phase nommée ci-dessous. Ce sont des corps UTF-8/LF complets avec une nouvelle ligne finale ; ne collez jamais les clôtures Markdown. Les fichiers exécutables inchangés héritent de l'entrée nommée. Les versions dans des variantes distinctes ne doivent pas écraser l'original.

docs/signup-recovery.md — DOC_LOST

# Recovered signup work

Keep a branch name before leaving useful experimental work.

Ouvrez la palette avec Commande+Maj+P (Ctrl+Maj+P sur Ubuntu).

1. Construisez la répétition comme le montre la section suivante et notez le sujet du commit perdu.
2. Ouvrez la palette et exécutez View Reflog…. La boîte de dialogue "Reflog" s'ouvre avec Reflog of défini sur HEAD ; les entrées sont répertoriées en premier.
3. Lisez les principales entrées. Le plus récent dit "réinitialiser" et celui ci-dessous dit "s'engager" avec le sujet "docs : conserver la note de récupération d'inscription". Utilisez Show Older Entries si la liste est longue. Ne présumez pas que la deuxième ligne est toujours la bonne.
4. Sélectionnez l’entrée de validation. La boîte de dialogue affiche Show in Graph et New branch name. Show in Graph ne peut placer qu'un commit atteint par une branche, donc pour ce commit perdu, il ferme la boîte de dialogue et le graphique reste sur M : rouvrez le reflog pour l'étape suivante. Vous lisez le fichier du commit après l'avoir restauré.
5. De retour dans la boîte de dialogue, sélectionnez la même entrée, tapez rescue/signup dans New branch name et choisissez Restore as Branch. L'avis indique "Sauvetage/inscription de branche créée. Annuler la supprime à nouveau."
6. Vérifiez le résultat : rescue/signup pointe vers le commit perdu, la branche actuelle est toujours private/lost-signup sur M et vos fichiers sont inchangés. Sélectionnez le commit restauré et ouvrez son fichier docs/signup-recovery.md : il s'agit de DOC_LOST.
7. Laissez la branche de secours en place. N'exécutez aucun nettoyage pour ranger le graphique.

Pour chaque commit ordinaire du cours : Summary est le sujet indiqué, Description est vide et les options Amend Previous Commit, Skip Hooks, Add Signed-off-by, Different Author, Push After Commit et Allow Empty Commit restent désactivées.

Uniquement dans une copie séparée et propre du résultat de la leçon 18 :

git switch --create private/lost-signup

Enregistrez DOC_LOST sous docs/signup-recovery.md, puis :

git add -- docs/signup-recovery.md
git commit --quiet -m "docs: keep the signup recovery note"
git reset --hard HEAD~1
git reflog show --format=%gs -2 HEAD

reset: moving to HEAD~1
commit: docs: keep the signup recovery note

Listez les candidats avec leurs identifiants et cochez celui que vous pensez perdu :

git reflog show --format='%H %gs' HEAD
git show "<lost-sha>:docs/signup-recovery.md"

Remplacez <lost-sha> par l'ID sur la ligne "commit: docs: keep the signup recovery note". Dans cet exemple immédiat, HEAD@{1} est le même commit, mais ce décalage n'est pas une règle. Créez la branche de secours sans la vérifier :

git branch rescue/signup "<lost-sha>"
git show rescue/signup:docs/signup-recovery.md
git symbolic-ref --short HEAD
git status --short

Le fichier est DOC_LOST, la branche imprimée est private/lost-signup et le statut est vide. Vos fichiers n'affichent pas la note, car HEAD est resté sur M. Aucune commande d'expiration ou de nettoyage n'en fait partie.

Where you end: rescue/signup pointe vers le commit perdu et son fichier est DOC_LOST. La branche actuelle, l'index et vos fichiers sont exactement tels qu'ils étaient après la réinitialisation, et rien n'a été poussé.

• Utiliser HEAD@{1} comme recette fixe au lieu de lire l'entrée.
• Réinitialiser ou vérifier à nouveau avant d'enregistrer une branche, ce qui ajoute plus d'entrées et enterre celle que vous souhaitez.
• S'attendre à ce que le reflog contienne une modification qui n'a jamais été validée.
• Exécuter des commandes de nettoyage tout en recherchant quelque chose.

Si le commit n'est pas dans la liste, vous regardez peut-être la mauvaise référence : basculez Reflog of entre HEAD et la branche et utilisez Show Older Entries. S'il a vraiment disparu, c'est qu'il a expiré ou n'a jamais été engagé. Dans l'application, l'avis après Restore as Branch indique qu'Annuler supprime à nouveau la branche.

Répondez à chaque question, puis lisez pourquoi. Les questions marquées « Obligatoire » comptent pour terminer la leçon.

1. Question 1 de 6

   Question 1 de 6

   Qu'est-ce que le reflog ?

   Choisissez une réponse.

   Un journal partagé que chaque clone et le serveur gardent en phase.

   Une sauvegarde de vos fichiers.

   Un enregistrement local de l'endroit où HEAD et chaque succursale ont pointé.

   La même chose que le graphique de validation.

   Vérifier la réponse
2. Question 2 de 6

   Question 2 de 6

   Lesquelles de ces affirmations sont vraies à propos du reflog ?

   Choisissez chaque réponse qui s'applique.

   Il stocke les modifications que vous n'avez jamais validées.

   HEAD et chaque branche ont la leur.

   Les anciennes entrées expirent.

   Un autre clone du projet n'a pas vos entrées.

   Vérifier la réponse
3. Question 3 de 6

   Question 3 de 6Obligatoire

   Vous avez trouvé le commit perdu dans le reflog et utilisé Restore as Branch avec le nom rescue/signup. Que vois-tu ?

   Choisissez une réponse.

   rescue/signup pointe vers le commit perdu, et vous êtes toujours sur private/lost-signup en M avec vos fichiers inchangés.

   Vous êtes maintenant sur rescue/signup et la note est de retour dans vos fichiers.

   private/lost-signup avance vers le commit perdu.

   L'entrée de reflog est supprimée.

   Vérifier la réponse
4. Question 4 de 6

   Question 4 de 6

   Modifiez l'entrée : vous n'avez jamais validé la note, puis vous avez exécuté la réinitialisation matérielle. Le reflog peut-il le ramener ?

   Choisissez une réponse.

   Oui, via Afficher les entrées plus anciennes.

   Oui, avec HEAD@{1}.

   Non. Le reflog pointe vers les commits, et ce contenu n'en a jamais été un.

   Oui, en basculant Reflog vers la branche.

   Vérifier la réponse
5. Question 5 de 6

   Question 5 de 6Obligatoire

   Vous avez effectué quelques opérations supplémentaires, puis exécuté git branch rescue HEAD@{1}, et le fichier n'est pas celui que vous souhaitiez. Ce qui s'est passé?

   Choisissez une réponse.

   HEAD@{1} est toujours le bon commit après une réinitialisation.

   Le reflog est corrompu.

   Le commit perdu a été supprimé par la nouvelle branche.

   HEAD@{1} compte à rebours à partir de maintenant, donc chaque nouvelle opération change son nom. Lisez la liste et utilisez l'ID du commit perdu.

   Vérifier la réponse
6. Question 6 de 6

   Question 6 de 6Obligatoire

   Après avoir créé la branche de secours, quelles relectures montrent qu'elle a fonctionné comme le dit la leçon ?

   Choisissez chaque réponse qui s'applique.

   docs/signup-recovery.md existe désormais dans vos fichiers.

   git show rescue/signup:docs/signup-recovery.md imprime la note récupérée, en commençant par "# Travail d'inscription récupéré".

   git status --short n'imprime rien.

   git symbolic-ref --short HEAD imprime private/lost-signup.

   Vérifier la réponse

Signalez les deux lignes de reflog les plus récentes, l'ID du commit perdu, la première ligne du fichier récupéré et la branche sur laquelle se trouve votre extraction. Dites ensuite ce que le reflog afficherait pour une modification que vous n'avez jamais validée.

• Le reflog est un journal local des mouvements d'arbitre.
• Vérifiez le candidat, puis branchez-le.
• Il trouve les validations, pas les modifications non enregistrées.

• Reset : soft, mixte et hard (leçon 27)
• Lire l'historique sans bouger la TÊTE (leçon 8)
• Télécharger GitTree

Reflog — سجل المراجع; branche de sauvetage — فرع حفظ ; sélecteur — محدِّد.