2.6 Les bases de Git - Étiquetage

Lister les étiquettes existantes dans Git est très simple. Tapez juste git tag :

Cette commande liste les étiquettes dans l’ordre alphabétique. L’ordre dans lequel elles apparaissent n’a aucun rapport avec l’historique.

Vous pouvez aussi rechercher les étiquettes correspondant à un motif particulier. Par exemple, le dépôt des sources de Git contient plus de 500 étiquettes. Si vous souhaitez ne visualiser que les séries 1.8.5, vous pouvez lancer ceci :

Git utilise deux types principaux d’étiquettes : légères et annotées.

Une étiquette légère ressemble beaucoup à une branche qui ne change pas, c’est juste un pointeur sur un commit spécifique.

Les étiquettes annotées, par contre, sont stockées en tant qu’objets à part entière dans la base de données de Git. Elles ont une somme de contrôle, contiennent le nom et l’adresse e-mail du créateur, la date, un message d’étiquetage et peuvent être signées et vérifiées avec GNU Privacy Guard (GPG). Il est généralement recommandé de créer des étiquettes annotées pour générer toute cette information mais si l’étiquette doit rester temporaire ou l’information supplémentaire n’est pas désirée, les étiquettes légères peuvent suffire.

Créer des étiquettes annotées est simple avec Git. Le plus simple est de spécifier l’option -a à la commande tag :

L’option -m permet de spécifier le message d’étiquetage qui sera stocké avec l’étiquette. Si vous ne spécifiez pas de message en ligne pour une étiquette annotée, Git lance votre éditeur pour pouvoir le saisir.

Vous pouvez visualiser les données de l’étiquette à côté du commit qui a été marqué en utilisant la commande git show :

Cette commande affiche le nom du créateur, la date de création de l’étiquette et le message d’annotation avant de montrer effectivement l’information de validation.

Une autre manière d’étiqueter les commits est d’utiliser les étiquettes légères. Celles-ci se réduisent à stocker la somme de contrôle d’un commit dans un fichier, aucune autre information n’est conservée. Pour créer une étiquette légère, il suffit de n’utiliser aucune des options -a, -s ou -m :

Cette fois-ci, en lançant git show sur l’étiquette, on ne voit plus aucune information complémentaire. La commande ne montre que l’information de validation :

Vous pouvez aussi étiqueter des commits plus anciens. Supposons que l’historique des commits ressemble à ceci :

Maintenant, supposons que vous avez oublié d’étiqueter le projet à la version v1.2 qui correspondait au commit « mise à jour rakefile ». Vous pouvez toujours le faire après l’évènement. Pour étiqueter ce commit, vous spécifiez la somme de contrôle du commit (ou une partie) en fin de commande :

Le commit a été étiqueté :

Par défaut, la commande git push ne transfère pas les étiquettes vers les serveurs distants. Il faut explicitement pousser les étiquettes après les avoir créées localement. Ce processus s’apparente à pousser des branches distantes — vous pouvez lancer git push origin [nom-du-tag].

Si vous avez de nombreuses étiquettes que vous souhaitez pousser en une fois, vous pouvez aussi utiliser l’option --tags avec la commande git push. Ceci transférera toutes les nouvelles étiquettes vers le serveur distant.

À présent, lorsqu’une autre personne clone ou tire depuis votre dépôt, elle obtient aussi les étiquettes.

Pour supprimer une étiquette de votre dépôt local, vous pouvez utiliser git tag -d <nom-d-etiquette>. Par example, nous pourrions supprimer notre étiquette légère ci-dessus, comme ceci :

Notez que ceci ne supprime pas l’étiquette sur aucun serveur distant. Il y a deux méthodes communes pour supprimer une étiquette d’un serveur distant.

La première est git push <distant> :refs/tags/<nom-d-etiquette>:

Ceci s’interprète comme une valeur nulle devant les deux points qui est envoyée sur le nom d’étiquette distante, ce qui l’efface.

La seconde manière (et la plus intuitive) pour supprimer une étiquette distante utilise l’option --delete :

Si vous souhaitez voir les versions de fichiers qu’une étiquette pointe, vous pouvez faire un git checkout de cette étiquette, bien que cela positionne votre dépôt dans un état « HEAD détachée », ce qui a quelques effets de bords malheureux :

Dans l’état « HEAD détachée », si vous modifiez puis créez un commit, l’étiquette restera identique, mais votre nouveau commit n’appartiendra à aucune branche et sera non joignable, à part avec son empreinte de commit exacte. Ainsi, si vous avez besoin de faire des modifications — disons que vous corrigez un bogue d’une ancienne version, par exemple — vous voudrez généralement créer une branche :

Si vous faites ceci et que vous faites un commit, votre branche V2.9.X sera légèrement différente de votre étiquette v2.9.1 puisqu’elle aura avancé avec les modifications que vous y aurez intégrées, donc faites attention.