Git Reflog : Comprendre et utiliser les journaux de référence dans Git

Il n'y a rien de plus ennuyeux pour un développeur ou un ingénieur de données que de supprimer accidentellement des branches git ou de réinitialiser des commits alors que vous ne le souhaitiez pas. C'est pourquoi je suis heureux de partager avec vous une chose que j'ai apprise par ma propre expérience et que j'aurais aimé apprendre plus tôt, à savoir comment utiliser git reflog. git reflog est l'une de ces techniques qui valent vraiment la peine d'être apprises ; si vous y consacrez un peu de temps aujourd'hui, vous pourrez vous épargner un gros mal de tête plus tard. 

Je vous montrerai git reflog, que je trouve très utile pour naviguer et récupérer des erreurs, mais je vous recommande également nos cours Foundations of Git et Introduction to GitHub Concepts pour apprendre tout ce qu'il y a à savoir sur le contrôle de version.

Qu'est-ce que git reflog ?

Le reflog Git, ou journal des références, est un mécanisme de suivi local qui enregistre les mises à jour des pointes de branches et de la référence HEAD dans un dépôt Git. (Dans le contexte de Git, HEAD fait référence au commit actuel sur lequel sont basés votre répertoire de travail et votre staging area).

Contrairement à git log, qui affiche l'historique des livraisons en fonction de l'ascendance, en montrant comment les livraisons sont liées dans une branche, git reflog capture tous les mouvements de HEAD, y compris les changements de branche, les rebasages, les réinitialisations et les livraisons. Cela rend reflog utile pour récupérer les commits perdus et déboguer les actions récentes.

Quand les entrées du journal de bord sont-elles créées ?

Des entrées Reflog sont créées chaque fois que vous effectuez des actions qui modifient l'état des références HEAD ou de branche. Les scénarios les plus courants sont les suivants :

• Commettre des modifications en utilisant git commit.

• Vous pouvez consulter une autre branche à l'aide de git checkout branch_name.

• Création d'une nouvelle branche à l'aide de git branch new_branch.

• Rebasage git rebase

• Rétablissement d'un commit antérieur git reset --hard.

• Fusionner les branches en utilisant git merge.

Voici le cursus que vous utilisez pour suivre les mises à jour dans le référentiel local :

git reflog

Utilisation de git reflog pour suivre les mises à jour dans le dépôt local. Image par l'auteur.

Comment interprétez-vous la sortie de git reflog ?

Vous pouvez interpréter le résultat comme suit :

• HEAD@{0}: L'action la plus récente a été de passer à la branche HEAD.

• HEAD@{1}: Auparavant, j'avais modifié un type de fichier du format .xlxs au format .csv.

• HEAD@{2}: J'ai fait le premier commit en poussant les fichiers vers le dépôt.

Chaque entrée indique

• Le hachage de la livraison (fa82776)

• L'index reflog (HEAD@{0}, HEAD@{1}, etc.)

• Une description de l'action entreprise (commit, checkout, rebase)

Comment utiliser git reflog

Git reflog permet de suivre les mises à jour des références et de restaurer l'état antérieur de votre dépôt. En comprenant comment naviguer dans les entrées de reflog, vous pouvez récupérer les modifications perdues, annuler les changements et comparer les versions antérieures de votre travail. 

Commande de base git reflog

Vous trouverez ci-dessous la commande de base reflog :

git reflog

La commande ci-dessus affiche une liste des actions récentes qui ont mis à jour les références HEAD ou de branche, y compris les commits, les changements de branche, les réinitialisations, les rebases, etc. Chaque entrée est indexée, par exemple HEAD@{0}, et HEAD@{1}, pour représenter sa position dans l'historique du reflog.

Référence à des états antérieurs

Le reflog Git sert d'enregistrement des mises à jour de référence passées, ce qui nous permet de localiser et de restaurer des points antérieurs dans l'historique de notre référentiel. Sans cela, ces références n'existeraient pas, et nous aurions besoin de hachages de livraisons exacts pour revenir à des états antérieurs spécifiques. Voyons maintenant comment Git nous permet de naviguer dans ces états passés à l'aide de git checkout.

HEAD@{n}: Fait référence à une entrée spécifique de reflog, où n est l'index. Par exemple, HEAD@{2} fait référence au troisième état le plus récent de HEAD.

git checkout HEAD@{2}

Utilisation du cursus git checkout pour suivre les modifications passées. Image par l'auteur.

branch@{time}: Fait référence à l'état d'une branche à un moment précis. Par exemple, main@{1.week.ago} fait référence à l'état de la branche principale il y a une semaine, tandis que feature@{yesterday} fait référence à l'état de la branche des fonctionnalités hier.

git checkout main@{1.week.ago}

Utilisation du cursus git checkout pour suivre les modifications passées. Image par l'auteur.

Qualifications basées sur le temps

git reflog nous aide non seulement à rétablir les états antérieurs, mais aussi à les comparer. Puisque le site reflog suit les mises à jour des références, nous pouvons l'utiliser pour voir comment notre référentiel a changé au fil du temps. Voyons maintenant comment git diff utilise les entrées de reflog pour comparer les états passés et présents.

Les exemples suivants sont des qualificatifs temporels qui facilitent la restauration de votre référentiel à un moment précis dans le temps plutôt que de s'appuyer uniquement sur les numéros d'index de reflog.

git checkout HEAD@{1.minute.ago}     # State from one minute ago

git checkout HEAD@{1.hour.ago}       # State from one hour ago

git checkout HEAD@{1.week.ago}       # State from one week ago

git checkout HEAD@{yesterday}        # State from yesterday

git checkout HEAD@{2024-01-01.12:00:00} # State at a specific timestamp

Comparer des états antérieurs avec git diff

Vous pouvez comparer les états antérieurs à l'aide de commandes telles que git diff. La commande suivante compare l'état actuel de la branche principale main@{0} avec son état d'il y a un jour, main@{1.day.ago}. La sortie montrera les différences entre ces deux instantanés.

git diff main@{0} main@{1.day.ago}

Comparaison d'états antérieurs avec git diff. Image par l'auteur.

Cas d'utilisation courants pour Git Reflog

Git reflog est un outil inestimable pour récupérer les modifications perdues, annuler les erreurs et réparer les mésaventures courantes de Git. Vous trouverez ci-dessous quelques scénarios pratiques dans lesquels git reflog peut vous aider.

Annulation d'une mauvaise réinitialisation

Si vous réinitialisez par erreur votre branche en utilisant git reset --hard, vous pouvez utiliser reflog pour rétablir l'état précédent.

git reset --hard HEAD@{3}

Récupérer les commits perdus

Si vous supprimez accidentellement une branche ou si vous perdez des commits à cause d'une réinitialisation ou d'un rebasement, vous pouvez retrouver le commit perdu en utilisant git reflog.

git reflog

Localisez le hash du commit à partir de la sortie de reflog et vérifiez-le :

git checkout <commit-hash>

Une fois que vous avez vérifié le commit perdu, vous pouvez créer une nouvelle branche pour le conserver :

git branch recovered-branch <commit-hash>

Correction d'un rebasement raté

Si un rebasement se passe mal, vous pouvez utiliser git reflog pour trouver le commit pré-rebase et réinitialiser votre branche. Identifiez le commit avant le rebasement et réinitialisez-le.

git reset --hard HEAD@{3}  # Adjust the number based on the reflog output

Restauration d'une branche supprimée

Si vous supprimez accidentellement une branche, vous pouvez la récupérer en utilisant git reflog. Trouvez le dernier commit connu de la branche supprimée et recréez-le :

git branch restored-branch <commit-hash>

Le cursus de l'histoire de la cachette

Git reflog peut également être utilisé pour afficher l'historique de la cachette. La commande ci-dessous énumère les opérations de stockage, ce qui vous permet de récupérer des stocks plus anciens si nécessaire. 

git reflog stash

Pour appliquer une entrée précédente de la réserve, utilisez la commande suivante :

git stash apply stash@{2}

Consultez notre site Git Pull Force : Comment écraser une branche locale avec une branche distante tutoriel pour apprendre les meilleures pratiques pour écraser les changements locaux.

Sous-commandes et options de Git Reflog

Git propose plusieurs sous-commandes et options pour gérer et interagir avec les reflogs. 

Sous-commandes de Git reflog

Vous trouverez ci-dessous une présentation structurée des principales sous-commandes de git reflog et de leur utilisation.

git reflog show: Affiche les entrées de reflog pour HEAD par défaut ou pour une référence spécifiée comme une branche.

git reflog show

Utilisation de git reflog show pour afficher les entrées pour la référence spécifiée. Image par l'auteur.

git reflog list: Cette commande affiche toutes les références avec un reflog. Il est utile pour identifier les branches et les références HEAD avec les entrées reflog stockées.

git reflog list

git reflog delete @{}: Nettoie les anciennes entrées de reflog qui dépassent la limite de temps spécifiée. Par exemple, la commande suivante supprime les entrées datant de plus de 30 jours.

git reflog expire --expire=30.days.ago

git reflog delete @{}: Supprime une entrée reflog particulière en fonction de sa référence et de sa position. La commande ci-dessous supprime l'entrée reflog à l'index 2 pour HEAD.

git reflog delete HEAD@{2}

git reflog exists : Vérifie si un reflog existe pour une référence spécifique. Par exemple, la commande ci-dessous renvoie un succès si la branche principale a un reflog.

git reflog exists main

Options pour les sous-commandes de git reflog

Vous trouverez ci-dessous les options disponibles pour les sous-commandes de git reflog et leur utilisation.

--expire-unreachable=: N'élague que les entrées de reflog qui sont inaccessibles à partir de n'importe quel ref. Par exemple, la commande ci-dessous supprime les entrées de journal de bord inaccessibles datant de plus de 7 jours.

git reflog expire --expire-unreachable=7.days.ago

--all: Traite les reflogs pour toutes les références, et pas seulement pour HEAD. La commande ci-dessous nettoie tous les reflogs datant de plus de 60 jours dans toutes les branches.

git reflog expire --expire=60.days.ago --all

--dry-run: Simule l'exécution d'une commande, en montrant ce qui serait élagué sans rien supprimer. Par exemple, la commande ci-dessous affiche les entrées qui seront supprimées.

git reflog expire --expire=30.days.ago --dry-run

--verbose: Fournit des informations détaillées sur les actions effectuées par la commande. La commande ci-dessous affiche les détails verbaux lors de l'expiration des anciennes entrées de reflog.

git reflog expire --expire=90.days.ago --verbose

Git Reflog vs. Journal Git : Principales différences

Les sites git log et git reflog fournissent tous deux des informations sur l'historique d'un dépôt, mais ils ont des objectifs différents. Examinons ces différences pour comprendre comment chacune d'entre elles peut être utilisée pour le contrôle des versions et les stratégies de récupération.

• git log montre l'historique des livraisons en suivant l'ascendance des livraisons dans une branche. Il fournit une vue chronologique de l'évolution du contenu du référentiel.

• git reflog enregistre les mises à jour de références telles que HEAD, les branches et les cachettes, y compris les actions telles que les changements de branche, les réinitialisations, les rebases, etc. Il cursus des changements qui peuvent ne pas faire partie de l'ascendance du commit.

• git reflog est strictement local à votre machine et n'est pas partagé avec des dépôts distants.

• Alors que git log ne peut pas récupérer les commits qui ne font plus partie de l'ascendance de la branche, git reflog peut aider à récupérer les commits "perdus" en suivant les mises à jour des références, même si ces commits ne sont plus accessibles à partir d'aucune branche.

Le tableau ci-dessous résume ces principales différences.

Git reflog est un outil puissant pour récupérer les commits perdus et corriger les problèmes d'historique, mais il faut être prudent pour l'utiliser efficacement. Voici quelques bonnes pratiques à suivre lorsque vous travaillez avec reflog.

• Utilisez Reflog pour la récupération et le débogage : Si vous avez accidentellement réinitialisé ou rebasé une branche de manière incorrecte, consultez git reflog pour retrouver une référence antérieure et la restaurer.

• Soyez prudent avec git reset --hard: git reset --hard peut supprimer de façon permanente des modifications non validées. Commencez toujours par vérifier la reconnexion afin de vous assurer que vous pouvez récupérer en cas de problème.

• Effectuez des sauvegardes avant d'exécuter des commandes destructrices : Pour vous protéger contre la perte de données, mettez en place des sauvegardes automatisées de vos dépôts Git. Conservez toujours les sauvegardes dans un endroit sûr, hors site, afin de garantir leur récupération en cas de défaillance matérielle ou d'autres catastrophes.

• Ne comptez pas uniquement sur Reflog pour un rétablissement à long terme : Par défaut, les entrées de reflog sont conservées pendant 90 jours. Passé ce délai, ils peuvent être mis au rebut et devenir irrécupérables. Poussez régulièrement vos modifications vers un dépôt distant pour vous assurer qu'elles sont préservées au-delà de votre reflog local.

• Utilisez git reflog expire pour gérer les anciennes entrées : Si le reflog de votre référentiel devient encombré, élaguez les entrées les plus anciennes ou inaccessibles en utilisant git reflog expire.

Conclusion

La gestion efficace de l'historique d'un projet dans Git ne se limite pas aux commandes de base. Le cursus d'outils avancés permettant de suivre les mises à jour des références peut constituer un filet de sécurité précieux pour récupérer les commits perdus, restaurer les branches supprimées et corriger les erreurs. L'acquisition d'une expérience pratique avec ces outils, ainsi qu'avec des commandes telles que git reset, git checkout, et git revert, peut considérablement améliorer vos compétences en matière de contrôle de version.

Suivre des cours DataCamp n'est pas seulement une excellente façon d'apprendre, mais c'est aussi un excellent moyen de signaler aux employeurs que vous prenez le développement de logiciels au sérieux. Pour cela, je vous recommande d'étudier notre article de blog Top 20 Git Interview Questions and Answers for All Levels et de suivre notre nouveau parcours de compétences Git Fundamentals pour devenir un expert en tout ce qui concerne Git.