Git Reflog
Cette page contient une discussion détaillée sur la commande git reflog. Git garde une trace des mises à jour sur la pointe des branches à l'aide d'un mécanisme appelé logs de référence ou « reflog ». De nombreuses commandes Git acceptent un paramètre pour spécifier une référence ou « réf », qui est un pointeur vers un commit. Quelques exemples communs :
Les reflogs permettent de suivre le moment où des réfs Git ont été mises à jour dans le dépôt local. Outre les reflogs de pointe de branche, un reflog spécial est conservé pour le stash Git. Les reflogs sont stockés dans des répertoires sous le répertoire .git du dépôt local. Les répertoires git reflog se trouvent ici : .git/logs/refs/heads/., .git/logs/HEAD et .git/logs/refs/stash si le stash Git a été utilisé dans le dépôt.
Nous avons discuté de git reflog à un niveau supérieur sur la page Réécriture de l'historique. Ce document couvrira : les options de configuration étendues de git reflog, les cas d'usage et inconvénients habituels de git reflog, comment annuler des changements avec git reflog, etc.
Utilisation basique
Le cas d'usage Reflog le plus basic appelle :
git reflogIl s'agit essentiellement d'un raccourci équivalent à :
git reflog show HEADCela génère le reflog HEAD. Vous devriez voir une sortie similaire à :
eff544f HEAD@{0}: commit: migrate existing content
bf871fd HEAD@{1}: commit: Add Git Reflog outline
9a4491f HEAD@{2}: checkout: moving from main to git_reflog
9a4491f HEAD@{3}: checkout: moving from Git_Config to main
39b159a HEAD@{4}: commit: expand on git context
9b3aa71 HEAD@{5}: commit: more color clarification
f34388b HEAD@{6}: commit: expand on color support
9962aed HEAD@{7}: commit: a git editor -> the Git editor
Ressource connexe
Fiche de révision sur Git
DÉCOUVRIR LA SOLUTION
Découvrir Git avec Bitbucket Cloud
Consultez la page Réécriture de l'historique pour découvrir un autre exemple d'accès reflog habituel.
Références reflog
DevOps touche toutes les phases du cycle de développement et opérationnel. De la planification au développement, en passant par la surveillance et l'itération, DevOps rassemble les compétences, les processus et les outils couvrant l'ensemble d'une organisation informatique et d'ingénierie.
Les méthodologies Agile aident les équipes à planifier et à produire en décomposant le travail en tâches et en étapes importantes gérables. Agile s'appuie sur des sprints, des backlogs, des epics et des stories pour assigner le travail à des membres qualifiés de l'équipe, ajuster les délais si nécessaire, et livrer des produits et services de qualité aux clients. En savoir plus sur Agile.
Intégration et livraison continues : l'intégration et la livraison continues sont les pierres angulaires des pratiques DevOps. Elles reposent sur le merge et le déploiement automatisés du code. Les méthodes de développement traditionnelles nécessitent que les ingénieurs mettent à jour manuellement les changements dans la base de code et effectuent des vérifications manuelles supplémentaires pour s'assurer que le code de qualité est prêt à être livré en production. Les déploiements sont programmés avec des délais de plusieurs semaines voire mois pour éliminer les probabilités de bugs ou d'incidents. Les pratiques DevOps suppriment ces délais en automatisant les fonctions de merge, de test et de déploiement. Les équipes ultra performantes appliquent la CI/CD pour modifier leur fréquence de déploiement de quelques mois à plusieurs fois par jour. En savoir plus sur la CI/CD.
Les dépôts et workflows Git offrent les fonctionnalités d'automatisation et de contrôle de version sur lesquelles reposent les pratiques DevOps. Comme Git est décentralisé, les opérations comme les commits, les blames, les diff, les merges et logs sont accélérées. Git prend également en charge la création de branches, le merge et la réécriture de l'historique des dépôts, ce qui permet des workflows et des outils puissants. En savoir plus sur Git.
La gestion des services informatiques (ITSM) est le processus utilisé par les équipes informatiques pour gérer la livraison de services informatiques de bout en bout auprès des clients. Elle comprend l'ensemble des processus et activités de conception, de création, de prestation et de support des services informatiques. Le concept fondamental de l'ITSM repose sur la conviction selon laquelle l'informatique devrait être fournie en tant que service, ce qui va au-delà du support informatique de base. Les équipes ITSM supervisent toutes sortes de technologies sur le lieu de travail, allant des ordinateurs portables aux serveurs, en passant par les apps logicielles essentielles. En savoir plus sur l'ITSM.
Les équipes de gestion des incidents répondent à un événement imprévu ou à une interruption de service et rétablissent le fonctionnement du service. Dans un modèle YBIYRI (you build it, you run it ou vous le développez, vous en êtes responsable), les développeurs s'associent à l'équipe opérationnelle pour réduire la probabilité qu'un incident se produise et le temps moyen jusqu'à la remise en route en cas d'incident. En savoir plus sur la gestion des incidents.
Par défaut, git reflog génère le reflog de la réf HEAD. HEAD est une référence symbolique à la branche active. Les reflogs sont également disponibles pour d'autres réfs. La syntaxe permettant d'accéder à git ref est name@{qualifier}. Outre les réfs HEAD, il est également possible de se référer à d'autres branches, tags, branches distantes, ainsi qu'au stash Git.
Vous pouvez obtenir un reflog complet de toutes les réfs en exécutant :
git reflog show --all
Pour voir le reflog d'une branche spécifique, changez le nom de cette branche en git reflog show
Bitbucket affiche la page Create a new repository (Créer un dépôt). Prenez quelques instants pour examiner le contenu de la boîte de dialogue. À l'exception du champ Repository type (Type de dépôt), tout ce que vous renseignez sur cette page peut changer ultérieurement.
git reflog show otherbranch
9a4491f otherbranch@{0}: commit: seperate articles into branch PRs
35aee4a otherbranch{1}: commit (initial): initial commit add git-init and setting-up-a-repo docsL'exécution de cet exemple affiche un reflog pour la branche otherbranch. L'exemple suivant suppose que vous avez stashé au préalable certains changements à l'aide de la commande git stash.
git reflog stash
0d44de3 stash@{0}: WIP on git_reflog: c492574 flesh out introCela génèrera un reflog pour le stash Git. Les pointeurs de réf renvoyés peuvent être transmis à d'autres commandes Git :
git diff stash@{0} otherbranch@{0}Exécuté, cet exemple de code affichera la sortie Git diff comparant les changements stash@{0} avec le réf otherbranch@{0}.
Reflogs programmés
Chaque entrée de reflog est liée à un horodatage. Ces horodatages peuvent être exploités comme le token qualifier de la syntaxe du pointeur de réf Git. Cela permet de filtrer les reflogs Git en fonction de l'heure. Voici quelques exemples de qualificatifs de temps disponibles :
1.minute.ago1.hour.ago1.day.agoyesterday1.week.ago1.month.ago1.year.ago2011-05-17.09:00:00
Les qualificatifs temporels peuvent être combinés (p. ex., 1.day.2.hours.ago), En outre, les formes plurielles sont acceptées (p. ex., 5.minutes.ago).
Les réfs de qualificatifs temporels peuvent être transmises à d'autres commandes git.
git diff main@{0} main@{1.day.ago} Cet exemple comparera la branche principale (main) à celle d'il y a un jour. Cet exemple est très utile si vous souhaitez connaître les changements survenus durant une certaine période.
Sous-commandes et options de configuration
git reflog accepte quelques arguments d'ajout considérés comme des sous-commandes.
Show – git reflog show
Par défaut, show est implicitement transféré. Par exemple, la commande :
git reflog main@{0} est équivalent à la commande :
git reflog show main@{0}
En outre, git reflog show est un alias pour git log -g --abbrev-commit --pretty=oneline. L'exécution de git reflog show affichera le journal du
Expire – git reflog expire
La sous-commande expire nettoie les entrées du reflog anciennes ou inaccessibles. La sous-commande expire est susceptible d'entraîner des pertes de données. Cette sous-commande est généralement utilisée par Git en interne, pas par les utilisateurs finaux. Le passage d'une option -n ou --dry-run à git reflog expire effectuera un « dry run » qui indiquera les entrées du reflog à supprimer, sans réellement les supprimer.
Par défaut, le délai d'expiration du reflog est de 90 jours. Une heure d'expiration peut être spécifiée en transférant un argument de ligne de commande --expire=time à git reflog expire ou en définissant un nom de configuration git de gc.reflogExpire.
Delete – git reflog delete
Le nom de la sous-commande delete parle de lui-même, et la commande supprime une entrée de reflog transmise. Comme pour expire, delete est susceptible d'entraîner une perte de données et est rarement appelée par les utilisateurs finaux.
Récupération de commits perdus
Git ne perd pas vraiment de contenu, même en effectuant des opérations de réécriture d'historique comme le rebasage ou la modification de commit. Pour l'exemple suivant, supposons que nous avons apporté de nouveaux changements à notre dépôt. Notre git log --pretty=oneline ressemble à ceci :
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsNous commitons ensuite ces changements et nous exécutons :
#make changes to HEAD
git commit -am "some WIP changes"Avec l'ajout du nouveau commit. Le journal ressemble à présent à ceci :
$ git clone
https://emmap1@bitbucket.org/emmap1/bitbucketstationlocations.git
Cloning into 'bitbucketspacestation'...
fatal: could not read
Password for 'https://emmap1@bitbucket.org': No such file or directorySi vous rencontrez cette erreur, saisissez ce qui suit dans la ligne de commande :
37656e19d4e4f1a9b419f57850c8f1974f871b07 some WIP changes
338fbcb41de10f7f2e54095f5649426cb4bf2458 extended content
1e63ceab309da94256db8fb1f35b1678fb74abd4 bunch of content
c49257493a95185997c87e0bc3a9481715270086 flesh out intro
eff544f986d270d7f97c77618314a06f024c7916 migrate existing content
bf871fd762d8ef2e146d7f0226e81a92f91975ad Add Git Reflog outline
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsÀ ce stade, nous effectuons un rebase interactif sur la branche principale en exécutant…
git rebase -i origin/mainDurant le rebase, nous marquons les commits à squasher avec la sous-commande de rebase s. Durant le rebase, nous squashons quelques commits dans le commit « quelques changements WIP » le plus récent.
Étant donné que nous avons squashé les commits, la sortie git log ressemble désormais à ceci :
40dhsoi37656e19d4e4f1a9b419f57850ch87dah987698hs some WIP changes
35aee4a4404c42128bee8468a9517418ed0eb3dc initial commit add git-init and setting-up-a-repo docsSi nous examinons git log à ce stade, les commits marqués pour le squashing n'apparaissent plus. Que faire si nous souhaitons effectuer une opération sur les commits squashés ? Peut-être pour enlever leurs changements de l'historique ? C'est une occasion d'exploiter le reflog.
git reflog
37656e1 HEAD@{0}: rebase -i (finish): returning to refs/heads/git_reflog
37656e1 HEAD@{1}: rebase -i (start): checkout origin/main
37656e1 HEAD@{2}: commit: some WIP changesNous voyons qu'il existe des entrées de reflog pour le début et la fin du rebase, et avant celles-ci se trouve notre commit « certains changements WIP ». Nous pouvons transmettre la réf de reflog à git reset, puis réinitialiser l'état d'un commit avant le rebase.
git reset HEAD@{2}L'exécution de cette commande de réinitialisation déplacera HEAD vers le commit où « certains changements WIP » a été ajouté, restaurant essentiellement les autres commits squashés.
Résumé
Dans ce tutoriel, nous avons discuté de la commande git reflog. Voici quelques points importants que nous avons couverts !
- Comment voir le reflog pour des branches spécifiques
- Comment annuler une commande git rebase avec le reflog
- Comment spécifier et afficher les entrées de reflog en fonction du temps
We briefly mentioned that git reflog can be used with other git commands like git checkout, git reset, and git merge. Learn more at their respective pages. For additional discussion on refs and the reflog, learn more here.
Partager cet article
Thème suivant
Lectures recommandées
Ajoutez ces ressources à vos favoris pour en savoir plus sur les types d'équipes DevOps, ou pour les mises à jour continues de DevOps chez Atlassian.
Le blog Bitbucket
Parcours de formation DevOps
