7.1 Utilitaires Git - Sélection des versions

Naturellement, vous pouvez référencer un commit par sa signature SHA-1, mais il existe des méthodes plus confortables pour les humains. Cette section présente les méthodes pour référencer un commit simple.

Git est capable de deviner de quel commit vous parlez si vous ne fournissez que quelques caractères du début de la signature, tant que votre SHA-1 partiel comporte au moins 4 caractères et ne correspond pas à plusieurs commits. Dans ces conditions, un seul objet correspondra à ce SHA-1 partiel.

Par exemple, pour afficher un commit précis, supposons que vous exécutiez git log et que vous identifiiez le commit où vous avez introduit une fonctionnalité précise.

Pour cet exemple, choisissons 1c002dd…​. Si vous affichez le contenu de ce commit via git show, les commandes suivantes sont équivalentes (en partant du principe que les SHA-1 courts ne sont pas ambigus).

Git peut déterminer une référence SHA-1 tout à la fois la plus courte possible et non ambigüe. Ajoutez l’option --abbrev-commit à la commande git log et le résultat affiché utilisera des valeurs plus courtes mais uniques ; par défaut Git retiendra 7 caractères et augmentera au besoin :

En règle générale, entre 8 et 10 caractères sont largement suffisants pour assurer l’unicité dans un projet. Par exemple, en février 2019, le noyau Linux (qui est un projet plutôt imposant) avait de plus de 875 000 commits et presque sept millions d’objets dont les empreintes SHA sont uniques à partir des 12 premiers caractères.

La méthode la plus commune pour désigner un commit est une branche y pointant. Dès lors, vous pouvez utiliser le nom de la branche dans toute commande utilisant un objet de type commit ou un SHA-1. Par exemple, si vous souhaitez afficher le dernier commit d’une branche, les commandes suivantes sont équivalentes, en supposant que la branche sujet1 pointe sur ca82a6d :

Pour connaître l’empreinte SHA sur laquelle pointe une branche ou pour savoir parmi tous les exemples précédents ce que cela donne en terme de SHA, vous pouvez utiliser la commande de plomberie nommée rev-parse. Référez-vous à Les tripes de Git pour plus d’informations sur les commandes de plomberie ; rev-parse sert aux opérations de bas niveau et n’est pas conçue pour être utilisée quotidiennement. Quoi qu’il en soit, elle se révèle utile pour comprendre ce qui se passe. Je vous invite à tester rev-parse sur votre propre branche.

Git maintient en arrière-plan un historique des références où sont passés HEAD et vos branches sur les derniers mois — ceci s’appelle le reflog.

Vous pouvez le consulter avec la commande git reflog :

À chaque fois que l’extrémité de votre branche est modifiée, Git enregistre cette information pour vous dans son historique temporaire. Vous pouvez référencer d’anciens commits avec cette donnée. Si vous souhaitez consulter le n-ième antécédent de votre HEAD, vous pouvez utiliser la référence @{n} du reflog, 5 dans cet exemple :

Vous pouvez également remonter le temps et savoir où en était une branche à une date donnée. Par exemple, pour savoir où en était la branche master hier (yesterday en anglais), tapez :

Cette technique fonctionne uniquement si l’information est encore présente dans le reflog et vous ne pourrez donc pas le consulter sur des commits plus vieux que quelques mois.

Pour consulter le reflog au format git log, exécutez: git log -g :

Veuillez noter que le reflog ne stocke que des informations locales, c’est un historique de ce que vous avez fait dans votre dépôt. Les références sont différentes pour un autre dépôt et juste après le clone d’un dépôt, votre reflog sera vide puisque qu’aucune activité n’aura été produite. Exécuter git show HEAD@{2.months.ago} ne fonctionnera que si vous avez dupliqué ce projet depuis au moins 2 mois — si vous l’avez dupliqué il y a 5 minutes, vous n’obtiendrez aucun résultat.

Une solution fréquente pour référencer un commit est d’utiliser son ascendance. Si vous suffixez une référence par ^, Git la résoudra comme étant le parent de cette référence. Supposons que vous consultiez votre historique :

Alors, vous pouvez consulter le commit précédent en spécifiant HEAD^, ce qui signifie « le parent de HEAD » :

Vous pouvez également spécifier un nombre après ^ — par exemple, d921970^2 signifie « le second parent de d921970 ». Cette syntaxe ne sert que pour les commits de fusion, qui ont plus d’un parent. Le premier parent est la branche depuis laquelle vous avez fusionné, et le second est le commit de la branche que vous avez fusionnée :

Une autre solution courante pour spécifier une référence ancêtre est le ~. Il fait également référence au premier parent, donc HEAD~ et HEAD^ sont équivalents. La différence apparaît si vous spécifiez un nombre. HEAD~2 signifie « le premier parent du premier parent », ou bien « le grand-parent » ; on remonte les premiers parents autant de fois que demandé. Par exemple, dans l’historique précédemment présenté, HEAD~3 serait :

Cela peut aussi s’écrire HEAD^, qui là encore est le premier parent du premier parent du premier parent :

Vous pouvez également combiner ces syntaxes — vous pouvez obtenir le second parent de la référence précédente (en supposant que c’était un commit de fusion) en utilisant HEAD~3^2, et ainsi de suite.

À présent que vous pouvez spécifier des commits individuels, voyons comment spécifier des plages de commits. Ceci est particulièrement pratique pour la gestion des branches — si vous avez beaucoup de branches, vous pouvez utiliser les plages pour répondre à des questions telles que « Quel travail sur cette branche n’ai-je pas encore fusionné sur ma branche principale ? ».