Comment vérifier si un commit Git fait partie d'un tag

Introduction

Dans ce laboratoire (lab), vous apprendrez à déterminer si un commit Git spécifique est inclus dans l'un des tags de votre projet. Cette compétence est précieuse pour comprendre quelles versions ou mises à jour contiennent des modifications particulières.

Grâce à des exercices pratiques, vous utiliserez la commande git tag --contains pour identifier les tags associés à un commit donné et explorerez la fonctionnalité de git describe pour vérifier les tags. Vous testerez également ces méthodes avec des commits non taggés pour consolider votre compréhension.

Skills Graph

Exécuter git tag --contains Commit

Dans cette étape, nous allons apprendre à utiliser la commande git tag --contains pour trouver quels tags contiennent un commit spécifique. Cela est utile lorsque vous voulez savoir quelles versions ou mises à jour de votre projet incluent une modification particulière.

Tout d'abord, assurons-nous que nous sommes dans le répertoire de notre projet. Ouvrez votre terminal et accédez au répertoire my-time-machine :

cd ~/project/my-time-machine

Maintenant, créons quelques commits et tags avec lesquels travailler. Nous allons ajouter un nouveau fichier et effectuer un commit :

echo "Another message for the future" > message2.txt
git add message2.txt
git commit -m "Add a second message"

Vous devriez voir une sortie similaire à celle-ci :

[master <commit-hash>] Add a second message
 1 file changed, 1 insertion(+)
 create mode 100644 message2.txt

Maintenant, ajoutons un tag à ce commit. Nous l'appellerons v1.0 :

git tag v1.0

Cette commande ne produit aucune sortie, mais elle a créé un tag pointant vers le dernier commit.

Faisons un autre commit sans tag :

echo "A third message" > message3.txt
git add message3.txt
git commit -m "Add a third message"

Vous devriez voir une sortie similaire à celle-ci :

[master <commit-hash>] Add a third message
 1 file changed, 1 insertion(+)
 create mode 100644 message3.txt

Maintenant, nous avons deux commits et un tag. Utilisons git log --oneline pour voir l'historique de nos commits :

git log --oneline

Vous devriez voir quelque chose comme cela (les identifiants de commit seront différents) :

<commit-hash> (HEAD -> master) Add a third message
<commit-hash> (tag: v1.0) Add a second message
<commit-hash> Send a message to the future

Remarquez que le tag v1.0 est associé au commit "Add a second message".

Maintenant, trouvons quels tags contiennent le commit "Add a second message". Nous avons besoin de l'identifiant de ce commit. Dans la sortie de git log --oneline, copiez l'identifiant du commit à côté de (tag: v1.0).

Remplacez <commit-hash> par l'identifiant réel que vous avez copié et exécutez la commande suivante :

git tag --contains <commit-hash>

Vous devriez voir v1.0 dans la sortie, car ce tag pointe directement vers ce commit.

Maintenant, essayons de trouver quels tags contiennent le premier commit ("Send a message to the future"). Copiez l'identifiant de ce commit dans la sortie de git log --oneline.

Remplacez <first-commit-hash> par l'identifiant réel et exécutez :

git tag --contains <first-commit-hash>

Vous devriez toujours voir v1.0 dans la sortie. C'est parce que v1.0 est sur un commit qui est un descendant du premier commit. Le flag --contains vérifie si le commit spécifié est un ancêtre du commit vers lequel le tag pointe.

Cette commande est très utile lorsque vous devez déterminer quelles versions de votre logiciel incluent une correction de bogue ou une fonctionnalité spécifique.

Utiliser git describe pour vérifier les tags

Dans cette étape, nous allons explorer la commande git describe. Cette commande est utilisée pour trouver le tag le plus récent accessible depuis un commit. Elle est particulièrement utile pour générer des noms lisibles par l'homme pour les commits, en particulier ceux qui ne sont pas directement taggés.

Assurez-vous que vous êtes toujours dans le répertoire ~/project/my-time-machine.

Tout d'abord, exécutons git describe sans aucun argument :

git describe

Étant donné que notre dernier commit n'est pas taggé, git describe cherchera le tag le plus proche, puis nous indiquera combien de commits ont été effectués depuis ce tag et fournira une version courte de l'identifiant du dernier commit. Vous devriez voir une sortie similaire à celle-ci :

v1.0-1-g<commit-hash>

Décortiquons cette sortie :

• v1.0 : C'est le tag le plus récent qui est un ancêtre du commit actuel.
• 1 : Cela indique qu'il y a 1 commit entre le tag v1.0 et le commit actuel.
• g<commit-hash> : Le g signifie "git" et <commit-hash> est un identifiant unique court pour le commit actuel.

Ce format est très utile pour identifier des builds ou des versions spécifiques de votre projet, même s'ils ne correspondent pas exactement à un tag.

Maintenant, essayons d'exécuter git describe sur le commit qui a le tag v1.0. Nous avons besoin de l'identifiant du commit "Add a second message". Vous pouvez l'obtenir à partir de git log --oneline.

Remplacez <commit-hash-of-v1.0> par l'identifiant réel et exécutez :

git describe <commit-hash-of-v1.0>

Cette fois, la sortie devrait simplement être :

v1.0

C'est parce que le commit spécifié est directement taggé avec v1.0. Lorsque le commit lui-même est taggé, git describe ne renvoie que le nom du tag.

La commande git describe est un outil puissant pour comprendre la relation entre vos commits et vos tags, offrant un moyen concis de nommer les commits en fonction de leur proximité au tag le plus proche.

Tester les commits non taggés

Dans cette étape, nous allons approfondir l'étude du comportement de git describe avec les commits qui ne sont pas directement taggés. Cela renforcera votre compréhension de la façon dont il trouve le tag le plus proche.

Assurez-vous que vous êtes dans le répertoire ~/project/my-time-machine.

Actuellement, nous avons un commit après le tag v1.0. Faisons un autre commit :

echo "Yet another message" > message4.txt
git add message4.txt
git commit -m "Add a fourth message"

Vous devriez voir une sortie similaire à celle-ci :

[master <commit-hash>] Add a fourth message
 1 file changed, 1 insertion(+)
 create mode 100644 message4.txt

Maintenant, exécutons à nouveau git describe :

git describe

Cette fois, la sortie devrait être similaire à :

v1.0-2-g<commit-hash>

Remarquez que le nombre entre v1.0 et l'identifiant du commit est maintenant 2. C'est parce qu'il y a maintenant deux commits sur la branche master depuis la création du tag v1.0. git describe compte correctement le nombre de commits depuis le commit taggé jusqu'au commit actuel.

Ce comportement est très utile dans les pipelines d'intégration continue et de déploiement, où vous pourriez vouloir générer automatiquement des noms de version pour les builds en fonction du dernier tag et du nombre de commits depuis ce tag.

Essayons encore une chose. Nous allons créer une nouvelle branche et effectuer un commit sur cette branche.

git checkout -b feature/new-feature
echo "Feature file" > feature.txt
git add feature.txt
git commit -m "Add feature file"

Vous devriez voir une sortie similaire à celle-ci :

Switched to a new branch 'feature/new-feature'
[feature/new-feature <commit-hash>] Add feature file
 1 file changed, 1 insertion(+)
 create mode 100644 feature.txt

Maintenant, exécutez git describe sur cette nouvelle branche :

git describe

La sortie devrait toujours être basée sur le tag v1.0, mais le nombre de commits et l'identifiant seront différents :

v1.0-3-g<commit-hash>

Même si nous sommes sur une autre branche, git describe trouve toujours le tag le plus proche accessible, qui est v1.0 dans ce cas. Le nombre de commits 3 reflète le nombre de commits depuis le tag v1.0 jusqu'au commit actuel sur la branche feature/new-feature (les deux commits sur master plus celui sur la branche de fonctionnalité).

Cela démontre comment git describe fonctionne entre les branches, en trouvant toujours le tag le plus proche dans l'historique des commits.

Résumé

Dans ce laboratoire (lab), nous avons appris à vérifier si un commit Git fait partie d'un tag en utilisant deux méthodes principales. Tout d'abord, nous avons exploré la commande git tag --contains <commit-hash>, qui liste directement tous les tags qui incluent le commit spécifié. Cela est particulièrement utile pour identifier quelles versions ou mises à jour intègrent un changement spécifique. Nous avons pratiqué cela en créant des commits et des tags, puis en utilisant git log --oneline pour obtenir les identifiants (hash) des commits et en effectuant ensuite des requêtes avec git tag --contains.

Deuxièmement, nous avons brièvement abordé l'utilisation de git describe comme une autre façon de relier les commits aux tags, bien que les étapes détaillées pour cela n'aient pas été entièrement fournies dans l'extrait. Le laboratoire incluait également une étape pour tester les commits non taggés, renforçant ainsi la compréhension du comportement de ces commandes lorsqu'un commit n'est associé à aucun tag. Dans l'ensemble, le laboratoire a offert une expérience pratique dans l'utilisation des commandes Git pour naviguer et comprendre la relation entre les commits et les tags dans l'historique d'un projet.