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 ce n’était pas voulu. C’est pourquoi je suis heureux de partager quelque chose que j’ai appris grâce à ma propre expérience et que j’aurais aimé apprendre plus tôt, c’est-à-dire comment utiliser git reflog. git reflog est l’une de ces techniques qui vaut vraiment la peine d’être apprise ; si vous y consacrez un peu de temps maintenant, vous pouvez éviter de gros problèmes à l’avenir.

Alors que je vais vous montrer git reflog, que je trouve vraiment utile pour naviguer et récupérer des erreurs, je tiens également à recommander nos cours Foundations of Git et Introduction to GitHub Concepts pour tout apprendre sur le contrôle de version.

Qu’est-ce que git reflog ?

Git reflog, ou journal de références, est un mécanisme de suivi local qui enregistre les mises à jour des pointes de branche 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 votre répertoire de travail et votre zone de staging sont basés.)

Contrairement à git log, qui affiche l’historique des commits basé sur la généalogie, montrant comment les commits sont connectés dans une branche, git reflog capture tous les mouvements de HEAD, y compris les changements de branche, les rebases, les réinitialisations et les commits. Cela rend reflog utile pour récupérer des commits perdus et déboguer les actions récentes.

Quand les entrées de reflog sont-elles créées ?

Les entrées de reflog sont créées chaque fois que vous effectuez des actions qui modifient l’état de HEAD ou des références de branche. Les scénarios courants incluent ce qui suit :

• Validation des modifications en utilisant git commit.

• Passage à une branche différente en utilisant git checkout nom_branche.

• Création d’une nouvelle branche en utilisant git branch nouvelle_branche.

• Rebaser avec git rebase

• Réinitialisation à un commit précédent git reset --hard.

• Fusionner des branches en utilisant git merge.

Voici le code que vous utilisez pour suivre les mises à jour dans le dépôt 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 la sortie comme suit :

• HEAD@{0} : La dernière action était de passer à la branche HEAD.

• HEAD@{1}: Avant cela, j’avais modifié un type de fichier de .xlxs au format .csv.

• HEAD@{2}: J’ai effectué le premier commit en poussant les fichiers dans le dépôt.

Chaque entrée montre :

• Le hachage du commit (fa82776)

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

• Une description de l’action effectuée (commit, checkout, rebase)

Comment utiliser git reflog

Git reflog offre un moyen de suivre les mises à jour des références et de restaurer les états précédents de votre dépôt. En comprenant comment naviguer dans les entrées du reflog, vous pouvez récupérer des commits perdus, annuler des changements et comparer les versions passées de votre travail.

Commande de base du reflog Git

Voici la commande de base du reflog :

git reflog

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

Référencer les états passés

Git reflog sert de registre des mises à jour de références passées, nous permettant de localiser et de restaurer les points précédents dans l’historique de notre dépôt. Sans cela, ces références n’existeraient pas, et nous aurions besoin des hachages de commit exacts pour revenir à des états passés spécifiques. Maintenant, explorons comment Git nous permet de naviguer dans ces états passés en utilisant git checkout.

HEAD@{n} : Fait référence à une entrée spécifique du 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 de git checkout pour suivre les changements passés. Image par l’auteur.

branch@{time}: Fait référence à l’état d’une branche à un moment spécifique. 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 de fonctionnalités hier.

git checkout main@{1.week.ago}

Utilisation de git checkout pour suivre les changements passés. Image par l’auteur.

Qualificateurs basés sur le temps

git reflog ne nous aide pas seulement à restaurer les états passés, mais nous permet également de les comparer. Puisque reflog suit les mises à jour de références, nous pouvons l’utiliser pour voir comment notre dépôt a changé au fil du temps. Maintenant, examinons comment git diff utilise les entrées de reflog pour comparer les états passés et présents.

Les exemples suivants sont des qualificateurs temporels qui facilitent la restauration de votre dépôt à un moment spécifique plutôt que de se fier uniquement aux numéros d’index de reflog.

git checkout HEAD@{1.minute.ago}     # État d'il y a une minute

git checkout HEAD@{1.hour.ago}       # État d'il y a une heure

git checkout HEAD@{1.week.ago}       # État d'il y a une semaine

git checkout HEAD@{yesterday}        # État d'hier

git checkout HEAD@{2024-01-01.12:00:00} # État à un moment spécifique

Comparer les états passés avec git diff

Vous pouvez comparer les états passés en utilisant des commandes comme 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}

Comparer les états passés avec git diff. Image par l’auteur.

Cas d’utilisation courants pour Git Reflog

Git reflog est un outil inestimable pour récupérer des modifications perdues, annuler des erreurs et corriger des incidents courants avec Git. Voici quelques scénarios pratiques où git reflog peut aider.

Annuler un mauvais reset

Si vous avez accidentellement réinitialisé votre branche en utilisant git reset --hard, vous pouvez utiliser reflog pour restaurer votre état précédent.

git reset --hard HEAD@{3}

Récupérer des commits perdus

Si vous supprimez accidentellement une branche ou perdez des commits à cause d’un reset ou d’un rebase, vous pouvez retrouver le commit perdu en utilisant git reflog.

git reflog

Localisez le hash du commit dans la sortie du 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 préserver :

git branch recovered-branch <commit-hash>

Correction d’un rebase raté

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

git reset --hard HEAD@{3}  # Ajustez le nombre en fonction de la sortie du reflog

Restaurer 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-la :

git branch restored-branch <commit-hash>

Suivi de l’historique des stash

Git reflog peut également être utilisé pour consulter l’historique des stash. La commande ci-dessous liste les opérations de stash, vous permettant de récupérer des stash plus anciens si nécessaire.

git reflog stash

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

git stash apply stash@{2}

Consultez notre Git Pull Force : Comment écraser une branche locale avec la version distante tutoriel pour apprendre les meilleures pratiques pour écraser les modifications locales.

Sous-commandes et options de Git Reflog

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

Sous-commandes de git reflog

Voici une répartition structurée des principales sous-commandes 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 une référence spécifiée. Image par l’auteur.

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

git reflog list

git reflog delete <ref>@{<specifier>} : 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 plus anciennes que 30 jours.

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

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

git reflog delete HEAD@{2}

git reflog exists <ref>: 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

Voici les options disponibles pour les sous-commandes de git reflog et leur utilisation.

--expire-unreachable=<time>: Élimine uniquement les entrées de reflog qui sont inatteignables depuis une référence. Par exemple, la commande ci-dessous supprime les entrées de reflog inatteignables datant de plus de 7 jours.

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

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

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

--dry-run: Simule l’exécution d’une commande, montrant ce qui serait élagué sans supprimer réellement quoi que ce soit. Par exemple, la commande ci-dessous affiche quelles entrées seraient supprimées.

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

--verbose: Fournit une sortie détaillée sur les actions effectuées par la commande. La commande ci-dessous affiche des détails verbeux tout en expirant d’anciennes entrées de reflog.

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

Différences clés entre le Reflog Git et le Log Git

À la fois git log et git reflog fournissent des informations sur l’historique d’un dépôt, mais ils ont des finalités différentes. Examinons ces différences pour comprendre comment chacun peut être utilisé pour le contrôle de version et les stratégies de récupération.

• git log montre l’historique des commits en suivant l’ascendance des commits dans une branche. Il fournit une vue chronologique de l’évolution du contenu du dépôt.

• git reflog enregistre les mises à jour des références telles que HEAD, les branches et les réserves, y compris des actions telles que les changements de branche, les réinitialisations, les rebases, et plus encore. Il suit les modifications qui peuvent ne pas faire partie de l’ascendance des commits.

• git reflog est strictement local à votre machine et n’est pas partagé avec les 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 de référence, même si ces commits ne sont plus accessibles depuis aucune branche.

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

Git reflog est un outil puissant pour récupérer des commits perdus et corriger des problèmes d’historique, mais son utilisation efficace nécessite de la prudence. Voici quelques meilleures pratiques à suivre lors de l’utilisation de 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 trouver une référence précédente et la restaurer.

• Soyez prudent avec git reset --hard: git reset --hard peut supprimer définitivement les modifications non validées. Vérifiez toujours d’abord le reflog pour 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 automatiques de vos dépôts Git. Stockez toujours les sauvegardes dans un endroit sécurisé et hors site pour garantir la récupérabilité en cas de défaillance matérielle ou d’autres catastrophes.

• Ne vous fiez pas uniquement au reflog pour la récupération à long terme:Par défaut, les entrées du reflog sont conservées pendant 90 jours. Après cette période, elles peuvent être collectées par le ramasse-miettes et devenir irrécupérables. Poussez régulièrement vos commits vers un dépôt distant pour vous assurer qu’ils sont préservés au-delà de votre reflog local.

• Utilisez git reflog expire pour gérer les anciennes entrées : Si le reflog de votre dépôt devient encombré, éliminez les entrées anciennes ou inaccessibles en utilisant git reflog expire.

Conclusion

La gestion efficace de l’historique d’un projet dans Git nécessite plus que de simples commandes de base. Explorer des outils avancés qui suivent les mises à jour des références peut fournir un filet de sécurité précieux pour récupérer des commits perdus, restaurer des branches supprimées et corriger des erreurs. Acquérir de l’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 votre compétence en matière de contrôle de version.

Suivre nos cours n’est pas seulement un excellent moyen d’apprendre, mais c’est aussi un excellent moyen de signaler aux employeurs que vous prenez le développement de logiciels au sérieux. À cette fin, je recommande d’étudier notre article de blog Top 20 des questions d’entretien Git et réponses pour tous les niveaux et de suivre notre nouvelle piste de compétences Fondamentaux de Git pour devenir un expert en tout ce qui concerne Git.