Comment vérifier si une étiquette Git pointe vers un commit spécifique

Introduction

Dans ce laboratoire, vous apprendrez à vérifier si une étiquette (tag) Git pointe vers un commit spécifique. Nous allons explorer la commande git rev-parse pour récupérer le hachage du commit associé à une étiquette, puis le comparer avec le hachage du commit réel extrait du journal (log) Git.

À travers des étapes pratiques, vous allez créer un simple dépôt Git, ajouter un fichier, effectuer un commit et créer une étiquette. Vous utiliserez ensuite git rev-parse pour trouver le hachage du commit de l'étiquette et vérifier son exactitude en le comparant au hachage du commit obtenu à partir du journal Git. Enfin, vous testerez ce processus avec différentes étiquettes pour consolider votre compréhension.

Skills Graph

%%%%{init: {'theme':'neutral'}}%%%% flowchart RL git(("Git")) -.-> git/BranchManagementGroup(["Branch Management"]) git(("Git")) -.-> git/BasicOperationsGroup(["Basic Operations"]) git/BasicOperationsGroup -.-> git/add("Stage Files") git/BasicOperationsGroup -.-> git/commit("Create Commit") git/BranchManagementGroup -.-> git/log("Show Commits") git/BranchManagementGroup -.-> git/tag("Git Tags") subgraph Lab Skills git/add -.-> lab-560115{{"Comment vérifier si une étiquette Git pointe vers un commit spécifique"}} git/commit -.-> lab-560115{{"Comment vérifier si une étiquette Git pointe vers un commit spécifique"}} git/log -.-> lab-560115{{"Comment vérifier si une étiquette Git pointe vers un commit spécifique"}} git/tag -.-> lab-560115{{"Comment vérifier si une étiquette Git pointe vers un commit spécifique"}} end

Exécuter git rev-parse sur une étiquette (Tag)

Dans cette étape, nous allons apprendre à utiliser la commande git rev-parse pour trouver le hachage du commit associé à une étiquette spécifique. Les étiquettes (tags) dans Git sont comme des marqueurs permanents sur votre historique, généralement utilisées pour marquer des points de version (comme v1.0, v2.0, etc.).

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 un simple fichier et effectuons un commit. Cela nous donnera quelque chose à étiqueter.

echo "This is the first version." > version.txt
git add version.txt
git commit -m "Add initial version file"

Vous devriez voir une sortie similaire à ceci après le commit :

[master <commit-hash>] Add initial version file
 1 file changed, 1 insertion(+)
 create mode 100644 version.txt

Maintenant, créons une étiquette pour ce commit. Nous l'appellerons v1.0.

git tag v1.0

Cette commande ne produit aucune sortie, mais elle a créé une étiquette légère nommée v1.0 pointant vers le commit actuel.

Pour voir les étiquettes dans votre dépôt, vous pouvez utiliser git tag :

git tag

Vous devriez voir :

v1.0

Maintenant, utilisons git rev-parse pour trouver le hachage du commit vers lequel l'étiquette v1.0 pointe.

git rev-parse v1.0

Cette commande affichera le hachage complet du commit :

<full-commit-hash>

La commande git rev-parse est très utile pour convertir diverses références Git (comme les étiquettes, les branches ou même des hachages de commit partiels) en leur hachage de commit complet. Cela est pratique lorsque vous avez besoin de l'identifiant exact d'un commit pour des scripts ou d'autres opérations Git.

Comparaison avec le hachage du commit

Dans l'étape précédente, nous avons utilisé git rev-parse v1.0 pour obtenir le hachage du commit associé à l'étiquette (tag) v1.0. Maintenant, comparons ce hachage avec le hachage du commit réel extrait du journal (log) Git pour confirmer qu'ils sont identiques.

Tout d'abord, assurez-vous que vous êtes toujours dans le répertoire ~/project/my-time-machine.

cd ~/project/my-time-machine

Maintenant, affichons le journal des commits en utilisant git log --oneline. L'option --oneline affiche chaque commit sur une seule ligne, ce qui est pratique pour voir rapidement l'historique des commits et leurs hachages courts.

git log --oneline

Vous devriez voir une sortie similaire à ceci :

<short-commit-hash> (HEAD -> master, tag: v1.0) Add initial version file

Remarquez le hachage court du commit au début de la ligne. Il s'agit de la version abrégée du hachage complet du commit. Vous pouvez également voir que l'étiquette v1.0 est listée à côté de ce commit, indiquant que l'étiquette pointe vers ce commit spécifique.

Maintenant, récupérons le hachage complet du commit en utilisant à nouveau git rev-parse v1.0 :

git rev-parse v1.0

Cela affichera le hachage complet du commit :

<full-commit-hash>

Comparez le hachage complet du commit obtenu avec git rev-parse avec le hachage court du commit obtenu avec git log --oneline. Le hachage court n'est que les premiers caractères du hachage complet. Ils font tous deux référence au même commit.

Cette comparaison démontre que git rev-parse <nom-de-l'étiquette> récupère avec succès le hachage du commit vers lequel l'étiquette spécifiée pointe. C'est un concept fondamental dans Git : les étiquettes ne sont que des pointeurs vers des commits spécifiques. Comprendre cette relation est essentiel pour naviguer efficacement dans l'historique de votre projet.

Tester différentes étiquettes (Tags)

Dans cette étape, nous allons créer un autre commit et une autre étiquette (tag) pour pratiquer davantage l'utilisation de git rev-parse avec différentes étiquettes. Cela renforcera votre compréhension de la manière dont les étiquettes pointent vers des commits spécifiques dans l'historique de votre projet.

Tout d'abord, assurez-vous que vous êtes dans le répertoire ~/project/my-time-machine.

cd ~/project/my-time-machine

Maintenant, modifions le fichier version.txt et créons un nouveau commit.

echo "This is the second version." >> version.txt
git add version.txt
git commit -m "Update version file to v2"

Vous devriez voir une sortie similaire à ceci après le commit :

[master <new-commit-hash>] Update version file to v2
 1 file changed, 1 insertion(+)

Nous avons maintenant créé un nouveau commit. Ajoutons une autre étiquette, v2.0, à ce dernier commit.

git tag v2.0

Encore une fois, cette commande ne produira pas de sortie, mais l'étiquette est créée.

Maintenant, listons toutes les étiquettes de notre dépôt :

git tag

Vous devriez voir les deux étiquettes :

v1.0
v2.0

Enfin, utilisons git rev-parse pour obtenir le hachage du commit pour la nouvelle étiquette, v2.0.

git rev-parse v2.0

Cela affichera le hachage complet du commit où vous avez créé l'étiquette v2.0 :

<full-commit-hash-for-v2>

Vous pouvez également utiliser git rev-parse pour obtenir le hachage de l'étiquette v1.0 à nouveau pour voir qu'elle pointe toujours vers le commit original :

git rev-parse v1.0

Cela affichera le hachage complet du commit où vous avez créé l'étiquette v1.0 (le même hachage que vous avez vu dans l'Étape 1) :

<full-commit-hash-for-v1>

En utilisant git rev-parse avec différents noms d'étiquettes, vous pouvez facilement récupérer le hachage de commit spécifique associé à chaque version étiquetée de votre projet. Cela est incroyablement utile pour naviguer dans l'historique de votre projet et référencer des points de version spécifiques.

Résumé

Dans ce laboratoire (lab), nous avons appris à vérifier si une étiquette (tag) Git pointe vers un commit spécifique. Nous avons commencé par utiliser la commande git rev-parse <tag> pour récupérer le hachage du commit associé à une étiquette donnée. Cette commande est un outil puissant pour convertir diverses références Git en leur hachage de commit complet.

Nous avons ensuite comparé le hachage du commit obtenu avec git rev-parse avec le hachage du commit réel trouvé dans le journal (log) Git pour vérifier que l'étiquette pointe bien vers le commit attendu. Ce processus nous permet de confirmer le commit exact que représente une étiquette, ce qui est crucial pour gérer les versions (releases) et suivre des points spécifiques dans l'historique du projet.