Comment vérifier si un commit Git est dans le reflog

Introduction

Dans ce laboratoire (lab), vous apprendrez à utiliser la puissante commande git reflog pour suivre l'historique de votre HEAD dans un dépôt Git. Vous découvrirez comment le reflog agit comme un journal personnel de vos actions, enregistrant les validations (commits), les fusions (merges), les rebasages (rebases) et bien plus encore, même pour les validations qui ne sont plus accessibles par aucune branche.

À travers des étapes pratiques, vous apprendrez à lister les entrées du reflog, à rechercher dans le reflog des hachages de validation (commit hashes) spécifiques et à comprendre comment les entrées du reflog expirent. Ce laboratoire vous dotera des connaissances nécessaires pour utiliser le reflog comme un outil essentiel pour récupérer des travaux perdus et comprendre l'historique de votre dépôt.

Skills Graph

Exécuter git reflog pour lister les entrées

Dans cette étape, nous allons explorer une puissante commande Git appelée git reflog. Imaginez le reflog comme votre journal personnel de chaque action que vous avez effectuée dans votre dépôt Git. Il enregistre lorsque vous avez validé (committed), modifié des validations (amended commits), fusionné des branches (merged branches), effectué un rebasage (rebased), et même lorsque vous avez accidentellement réinitialisé votre dépôt.

La commande git reflog est incroyablement utile pour récupérer des validations perdues ou comprendre l'historique de votre dépôt, même si ces validations ne sont plus accessibles par aucune branche.

Voyons le reflog de notre dépôt my-time-machine. Tout d'abord, assurez-vous d'être dans le bon répertoire :

cd ~/project/my-time-machine

Maintenant, exécutez la commande git reflog :

git reflog

Vous devriez voir une sortie similaire à celle-ci :

a1b2c3d (HEAD -> master) HEAD@{0}: commit: Send a message to the future
a1b2c3d (HEAD -> master) HEAD@{1}: initial commit (master)

Décortiquons cette sortie :

• a1b2c3d : Il s'agit du hachage court de validation (short commit hash), un identifiant unique pour chaque validation.
• (HEAD -> master) : Cela indique que le HEAD (votre position actuelle) et la branche master pointent vers cette validation.
• HEAD@{0} : Il s'agit de l'entrée du reflog pour l'état actuel du HEAD. Le nombre entre accolades {} indique combien d'étapes en arrière cette entrée a été créée. {0} est l'entrée la plus récente.
• HEAD@{1} : Il s'agit de l'entrée précédente du reflog.
• commit: Send a message to the future : Il s'agit de l'action qui a été effectuée (une validation) et du message de validation.
• initial commit (master) : Cela indique la validation initiale lors de la création du dépôt.

Le reflog montre un historique chronologique de l'emplacement de votre HEAD. Cela diffère de git log, qui montre l'historique des validations accessibles depuis la branche actuelle. Le reflog suit vos actions, ce qui en fait un filet de sécurité pour récupérer des travaux perdus.

Comprendre le reflog est comme avoir une carte détaillée de vos aventures dans le temps. Il vous montre tous les endroits que vous avez visités, même si vous êtes depuis passé à une autre ligne temporelle (branche).

Rechercher un hachage de validation (commit hash) dans le reflog

Dans l'étape précédente, nous avons vu la sortie de la commande git reflog. Chaque entrée du reflog correspond à un état spécifique du HEAD de votre dépôt. Ces états sont identifiés par un hachage de validation (commit hash).

Parfois, vous devrez peut-être trouver un point spécifique dans l'historique de votre reflog, peut-être pour récupérer une validation perdue ou pour voir à quoi ressemblait votre dépôt à un moment précis. Vous pouvez utiliser le hachage de validation de la sortie de git reflog pour faire référence à ces points spécifiques.

Essayons de visualiser l'état de notre dépôt au moment de la validation initiale. D'après la sortie de git reflog de l'étape précédente, l'entrée de la validation initiale ressemblait à ceci :

a1b2c3d (HEAD -> master) HEAD@{1}: initial commit (master)

Le hachage de validation de la validation initiale est a1b2c3d (votre hachage sera différent). Nous pouvons utiliser ce hachage avec les commandes Git pour faire référence à cet état spécifique.

Par exemple, pour afficher les détails de la validation initiale en utilisant son hachage, vous pouvez utiliser git show suivi du hachage. Remplacez a1b2c3d par le véritable hachage de la validation initiale issu de la sortie de votre commande git reflog.

git show a1b2c3d

Vous devriez voir une sortie similaire à celle-ci, montrant les détails de la validation initiale :

commit a1b2c3d4e5f6g7h8i9j0k1l2m3n4o5p6q7r8s9
Author: Jane Doe <[email protected]>
Date:   Mon Aug 7 10:00:00 2023 +0000

    Send a message to the future

diff --git a/message.txt b/message.txt
new file mode 100644
index 0000000..e69de29
--- /dev/null
+++ b/message.txt
@@ -0,0 +1 @@
+Hello, Future Me

Cela montre comment vous pouvez utiliser les hachages de validation du reflog pour identifier précisément des moments spécifiques dans l'historique de votre dépôt. C'est une compétence essentielle pour naviguer dans Git et récupérer d'erreurs.

N'oubliez pas que le reflog est votre filet de sécurité. Même si une validation n'est plus partie de l'historique d'une branche, tant qu'elle est dans le reflog, vous pouvez généralement la trouver et la récupérer en utilisant son hachage.

Tester les entrées expirées du reflog

Dans cette étape, nous allons apprendre comment Git gère le reflog et comment les entrées peuvent éventuellement expirer. Par défaut, Git conserve les entrées du reflog pendant une certaine période. Les entrées accessibles (celles pointées par une branche ou une étiquette) sont conservées pendant 90 jours, tandis que les entrées inaccessibles (celles qui ne sont pointées par rien) sont conservées pendant 30 jours. Après ces périodes, le processus de nettoyage des données inutiles (garbage collection) de Git peut les supprimer.

Bien que nous ne puissions pas simuler le passage du temps dans ce laboratoire pour voir les entrées expirer naturellement, nous pouvons déclencher manuellement le nettoyage des données inutiles de Git avec une option spécifique pour supprimer les anciennes entrées du reflog.

Important : L'exécution de cette commande supprimera les anciennes entrées du reflog en fonction des délais d'expiration configurés. Dans un scénario réel, vous n'auriez généralement pas besoin d'exécuter cela manuellement, sauf si vous avez une raison spécifique pour nettoyer les anciennes entrées du reflog.

Tout d'abord, assurez-vous d'être dans le répertoire my-time-machine :

cd ~/project/my-time-machine

Maintenant, exécutons la commande de nettoyage des données inutiles avec l'option de suppression pour les entrées du reflog. Nous allons définir un délai d'expiration très court pour les entrées inaccessibles pour démontrer l'effet.

git gc --prune=now --aggressive

Cette commande demande à Git d'exécuter le nettoyage des données inutiles immédiatement (--prune=now) et de manière agressive (--aggressive) pour nettoyer les objets libres et supprimer les entrées inaccessibles du reflog.

Après avoir exécuté la commande, vérifions le reflog à nouveau :

git reflog

Vous pourriez constater que certaines anciennes entrées, surtout si vous aviez effectué plus d'opérations avant ce laboratoire, ont peut-être disparu. Dans notre dépôt simple avec seulement deux entrées de reflog, il est possible que les deux soient toujours présentes car elles sont relativement nouvelles et l'une est toujours accessible via HEAD et master. Cependant, si vous aviez un historique plus complexe avec des validations inaccessibles, cette commande les supprimerait en fonction des paramètres d'expiration.

Le principal enseignement ici est que le reflog n'est pas permanent. Git nettoie les anciennes entrées pour économiser de l'espace. Cependant, pour les flux de travail de développement typiques, les délais d'expiration par défaut sont généralement suffisants pour récupérer la plupart des erreurs.

Comprendre que les entrées du reflog ont une date d'expiration vous aide à apprécier l'importance de créer des validations et des branches significatives pour préserver les points importants de l'historique de votre projet.

Résumé

Dans ce laboratoire, nous avons appris à utiliser la commande git reflog pour afficher l'historique chronologique des emplacements du HEAD dans un dépôt Git. Nous avons vu que le reflog agit comme un journal personnel d'actions, enregistrant les validations (commits), les fusions (merges), les rebasages (rebases) et d'autres opérations, même pour les validations non accessibles par aucune branche. Nous avons examiné la sortie de git reflog, en comprenant les éléments tels que les hachages de validation (commit hashes), les pointeurs HEAD, les indices des entrées du reflog (par exemple, HEAD@{0}) et l'action effectuée.

Ensuite, nous avons exploré comment rechercher un hachage de validation spécifique dans le reflog pour déterminer si une validation particulière existe dans l'historique du reflog. Enfin, nous avons brièvement abordé le concept d'entrées expirées du reflog, en comprenant que les entrées du reflog ne sont pas permanentes et sont éventuellement supprimées. Ce laboratoire a démontré le pouvoir de git reflog comme outil essentiel pour comprendre l'historique du dépôt et récupérer des travaux potentiellement perdus.