Git est le système de contrôle de version le plus largement utilisé aujourd'hui, et il garde une trace des changements de différentes manières pour s'assurer que vous ne perdez jamais un changement validé. De plus, le contrôle qu'il vous donne sur les workflows de développement signifie que vous pouvez déterminer exactement à quoi ressemble l'historique de votre projet. Git dispose de plusieurs mécanismes pour réécrire l'historique des commits afin d'aider à cela, notamment git commit --amend , git rebase et git reflog .

Dans cet article, vous apprendrez à utiliser git reflog pour réorganiser et réécrire votre historique de validation Git efficacement et facilement, tout en atténuant le risque que la réécriture de l'historique de validation entraîne souvent.

Qu'est-ce qu'un reflog ?

Git utilise un système appelé journal de référence , ou simplement " reflog ", pour suivre les modifications apportées aux astuces des branches. Une référence, souvent appelée " ref ", est un pointeur vers un commit ou une branche que de nombreuses commandes Git acceptent comme paramètre. git checkout , git reset et git merge sont des exemples de commandes git courantes qui acceptent les références comme paramètres.

Par défaut, les reflogs gardent une trace de chaque position HEAD au cours des 90 derniers jours. De plus, l'historique de reflog est exclusif au référentiel et n'est pas accessible à distance. Outre les reflogs de pointe de branche, il existe un reflog séparé pour le stash Git .

Les reflogs sont stockés dans des répertoires spécifiques sous le répertoire .git du référentiel local. Ces git reflog peuvent être trouvés à .git/logs/refs/heads/. , .git/logs/HEAD , et aussi .git/logs/refs/stash si le git stash a été utilisé sur le dépôt.

Configuration de base

Les commandes de base de reflog sont les suivantes :

 # To see activity on HEAD git reflog show

Le résultat de la commande ci-dessus ressemble à ce qui suit :

 0a2e358 HEAD@{0}: reset: moving to HEAD~2 0254ea7 HEAD@{1}: checkout: moving from 2.2 to main c10f740 HEAD@{2}: checkout: moving from main to 2.2

Les autres utilisations courantes sont les suivantes :

 # To see activity on HEAD, including timestamp git reflog show --date=relative #or git reflog --relative-date # same, on some_branch git reflog show --date=relative some_branch

Références à Reflog

Par défaut, git reflog le reflog de la référence HEAD . Le symbole HEAD désigne la branche actuellement active. Il existe également des reflogs disponibles pour d'autres refs. La syntaxe utilisée pour accéder à une référence git est name@{qualifier} , par exemple - otherbranch@{0} . En plus des références HEAD , d'autres branches, balises, télécommandes et stash Git peuvent également être référencés.

Pour voir le reflog complet de toutes les références, vous pouvez exécuter :

 git reflog show --all

Outre les index ordonnés, chaque entrée de reflog est associée à un horodatage qui peut également être utilisé comme jeton de qualification pour la syntaxe du pointeur de référence Git. C'est ce qui permet de filtrer ces entrées de reflog par heure. Voici des exemples de qualificatifs de temps couramment utilisés :

• @{0}
• @{6.minutes.ago}
• @{2.hour.ago}
• @{3.day.ago}
• @{5.weeks.ago}
• @{8.years.ago}
• @{today}
• @{2022-01-23.08:30:00}
• @{1.day.10.hours.ago}

Ces qualificatifs de temps peuvent être combinés (par exemple 1.day.3.hours.ago ). Les formes plurielles de ces qualificatifs de temps sont également acceptées (par exemple 5.minutes.ago ). Ils peuvent être utilisés avec la commande git reflog comme suit :

 git reflog show develop@{3.days.ago}

Sous-commandes et options de configuration

git reflog accepte des arguments supplémentaires qui sont donc considérés comme des sous-commandes, telles que show , expire et delete . Discutons de ces sous-commandes en détail.

spectacle git reflog

Comme indiqué précédemment, show est implicitement passé par défaut. L'exécution git reflog show affichera le journal des arguments passés.

Par exemple:

 git reflog develop@{0}

est le même que

 git reflog show develop@{0}

De plus, git reflog show est un alias pour git log -g --abbrev-commit --pretty=oneline .

git reflog expire

La sous-commande expire aide à nettoyer les entrées de reflog anciennes ou inaccessibles.

La sous-commande expire peut entraîner une perte de données.

Cependant, cette sous-commande n'est généralement pas utilisée par les utilisateurs finaux mais par git en interne.

Une "exécution à blanc" peut être effectuée en passant une option -n ou --dry-run à git reflog expire pour afficher quelles entrées de reflog sont marquées pour être élaguées, de sorte qu'elles ne seront pas réellement élaguées. Cela peut servir de filet de sécurité lors du nettoyage des entrées de reflog expirées.

De plus, le délai d'expiration peut être spécifié en passant un argument de ligne de commande --expire=time à git reflog expire ou en définissant un nom de configuration git de gc.reflogExpire .

git reflog supprimer

La sous-commande delete, comme son nom l'indique, supprime l'entrée de reflog transmise. La suppression, comme l'expiration, peut entraîner une perte de données et n'est pas fréquemment utilisée par les utilisateurs finaux.

git reflog contre git log

git reflog et git log sont les deux composants du même nom fournis par Git qui nous permettent de nous faufiler dans l'historique de validation, les journaux et les reflogs du référentiel. Le fait que les deux composants affichent souvent le même historique, en particulier lorsqu'un développeur effectue un certain nombre de validations locales sans extraction ou extraction, est l'une des raisons de la confusion entre le reflog Git et le journal.

Cependant, ceux-ci sont essentiellement différents et ont des cas d'utilisation différents.

Comprenons les différences sous-jacentes ainsi que les similitudes des deux commandes ci-dessus.

La différence la plus notable entre le reflog Git et le journal est que le journal est un enregistrement public de l'historique des commits du référentiel, tandis que le reflog est un enregistrement privé, spécifique à l'espace de travail, des commits locaux du référentiel.

Après un push, un fetch ou un pull, le journal Git est répliqué dans le référentiel Git. Le reflog Git, en revanche, n'est pas inclus dans le référentiel dupliqué. Sans accès physique à l'ordinateur sur lequel le référentiel local est conservé, un développeur ne peut pas examiner le reflog.

Le reflog est un fichier trouvé dans .git\logs\refs\heads qui suit l'historique des commits locaux pour une branche spécifique et exclut tous les commits qui peuvent avoir été élagués par les processus de récupération de place de Git. Le journal Git, d'autre part, fournit une traversée historique des commits d'une branche qui commence par le commit le plus récent et se termine par le tout premier commit de l'historique de la branche.

Git reflog comme filet de sécurité

Git reflog peut être utilisé comme filet de sécurité pendant le développement car vous ne pouvez pas perdre de données de votre référentiel une fois qu'il a été validé si vous comprenez correctement le concept de reflog. Vous pouvez utiliser le reflog pour voir où vous étiez avant et git reset --hard pour revenir à cette référence pour restaurer votre état antérieur si vous réinitialisez involontairement un commit plus ancien, rebasez de manière incorrecte ou effectuez toute autre opération qui "supprime" visiblement engage.

N'oubliez pas que les références font référence à l'historique complet du commit, pas seulement au commit lui-même.

Conclusion

Dans cet article, nous avons discuté des options de configuration étendues de git reflog , des cas d'utilisation courants et des pièges de git reflog .

Pour résumer, Git conserve un reflog, qui est un journal de l'endroit où se trouvaient vos références HEAD et de branche au cours des derniers mois (90 jours), en arrière-plan pendant que vous travaillez. Git enregistre des informations dans cet historique temporaire chaque fois que votre astuce de branche est modifiée pour une raison quelconque.

La commande reflog peut également être utilisée pour supprimer ou faire expirer les entrées trop anciennes du reflog. La sous-commande expire the est utilisée pour supprimer les entrées de reflog obsolètes et la sous-commande delete est utilisée pour supprimer et spécifier l'entrée spécifique à supprimer du reflog.