guides

Un tag Git est une référence nommée qui pointe vers un commit précis d'un dépôt. Là où un commit est identifié par un long hash difficile à retenir, un tag donne à ce point exact de l'historique un nom court et lisible. Les tags servent le plus souvent à marquer des points de release, de sorte qu'un nom comme v1.0.0 désigne l'état précis du code livré sous cette version.

La différence essentielle entre un tag et une branche est qu'un tag ne bouge pas. Une branche est un pointeur qui avance chaque fois que vous y ajoutez un nouveau commit, suivant toujours le travail le plus récent. Un tag est figé : une fois attaché à un commit, il continue de pointer vers ce même commit même si le développement se poursuit au-delà. C'est exactement ce que l'on attend d'une release, car la signification de v1.0.0 ne doit jamais changer après sa publication.

Tags légers ou tags annotés

Git prend en charge deux types de tags : les tags légers et les tags annotés. Un tag léger n'est guère plus qu'un nom pointant directement vers un commit, sans information supplémentaire stockée à côté. Il est rapide à créer et fonctionne bien comme marque-page personnel, mais il ne conserve aucune trace de qui l'a créé ni pourquoi.

Un tag annoté est stocké comme un objet complet dans la base de données de Git. Il enregistre le nom de la personne qui a créé le tag, la date de création et un message de tag, à peu près de la même façon qu'un commit enregistre son auteur et son message. Les tags annotés peuvent aussi être signés avec GPG, ce qui permet à d'autres de vérifier qu'un tag de release provient réellement de vous. Pour les releases publiques, les tags annotés sont généralement recommandés en raison de ces métadonnées supplémentaires et de la possibilité de les signer.

Créer et pousser des tags

Créer des tags est simple. Exécuter git tag avec un nom et sans autre option crée un tag léger sur le commit courant. Ajouter l'option -a, comme dans git tag -a v1.0.0 -m "Release 1.0.0", crée un tag annoté avec un message. Vous pouvez aussi taguer un commit plus ancien en passant son hash à la fin de la commande, ce qui est utile lorsque vous réalisez après coup qu'un commit particulier était le vrai point de release.

• Un tag nomme un commit précis ; contrairement à une branche, il ne bouge plus une fois posé.
• Tag léger : un simple nom pointant vers un commit, sans métadonnées supplémentaires.
• Tag annoté : un objet complet stockant auteur, date et message, et pouvant être signé avec GPG.
• Création avec git tag v1.0.0 (léger) ou git tag -a v1.0.0 -m "..." (annoté).
• Les tags ne sont pas poussés par défaut : envoyez-les avec git push origin <tag> ou git push --tags.
• Les tags marquent les releases, souvent en SemVer vX.Y.Z, et déclenchent souvent la CI/CD et les pages de release.

Un point qui surprend les débutants est que les tags ne sont pas partagés automatiquement. Quand vous exécutez git push, vos branches sont mises à jour sur le dépôt distant, mais vos tags restent locaux à moins de les envoyer explicitement. Vous poussez un seul tag avec git push origin suivi du nom du tag, ou vous envoyez tous vos tags d'un coup avec git push --tags. Oublier cette étape est une raison fréquente pour laquelle un tag de release apparaît sur la machine d'un développeur mais manque dans le dépôt partagé.

Tags, versionnage et automatisation des releases

Les tags s'intègrent naturellement dans un schéma de versions. Beaucoup de projets suivent le versionnage sémantique, où une version a la forme MAJEUR.MINEUR.CORRECTIF, et chaque release est capturée par un tag correspondant tel que v2.4.1. Comme le tag est immuable, n'importe qui peut plus tard extraire ce tag exact et reconstruire le code tel qu'il était pour cette version, ce qui constitue le fondement des releases reproductibles.

Les tags alimentent aussi une grande partie de l'automatisation. Les pipelines d'intégration et de déploiement continus sont souvent configurés pour se déclencher lorsqu'un nouveau tag est poussé, de sorte que taguer un commit v1.2.0 construit, teste et publie automatiquement cette version. Les plateformes qui hébergent des dépôts transforment souvent les tags en pages de release, en y attachant des notes et des artefacts téléchargeables pour chaque version taguée. Ainsi, un petit pointeur immuable devient l'ancre de tout un processus de release.

Travailler avec les tags en toute sécurité

Parce qu'un tag n'est qu'une référence, il est peu coûteux et sûr à manipuler. Lister les tags, inspecter ce que dit un tag annoté ou extraire le code à un tag donné sont des opérations en lecture seule qui ne perturbent pas votre travail en cours. Supprimer un tag localement est également simple, mais supprimer un tag déjà poussé et utilisé par d'autres demande de la prudence, car des personnes et des pipelines peuvent déjà en dépendre.

En résumé

En résumé, un tag Git est une étiquette stable posée sur un moment de l'historique de votre projet. Les tags légers sont des repères personnels rapides, tandis que les tags annotés portent une paternité, un message et des signatures optionnelles qui les rendent adaptés aux releases publiques. Combinés à un schéma de versions et poussés vers le dépôt distant partagé, les tags transforment un hash de commit impossible à mémoriser en une référence durable et vérifiable pour une version précise de votre logiciel.