Les tags : identifier des points d’historique

Tu préfères une vidéo ?

Si tu es du genre à préférer regarder que lire pour apprendre, on a pensé à toi :

Quels rôles ?

Comme je l’ai dit précédemment, on utilise généralement les tags pour marquer une version logicielle, mais on peut très bien les utiliser pour d’autres raisons. On peut avoir besoin de marquer temporairement un endroit dans l’historique, ou on peut vouloir conserver une partie d’historique sans pour autant garder la branche associée.

Certaines personnes utilisent les tags comme évènements déclencheurs pour des automatisations, comme un déploiement en environnement de production par exemple. Cette pratique est généralement faite du côté des interfaces des serveurs Git, comme GitHub et GitLab.

À toi donc de choisir le ou les rôles qui te conviendront le mieux.

2 types de tags

Les tags peuvent être simples ou annotés. La différence réside dans le fait qu’un tag simple représente une simple étiquette nommée quand le tag annoté renseigne en plus des métadonnées (auteur·e du tag, horodatage, message).

La documentation officielle recommande l’emploi des tags annotés pour les versions logicielles afin de renseigner en message une description de la version marquée. Personnellement je me contente de tags simples car je préfère décrire les évolutions dans un fichier intégré au projet, généralement appelé release notes ou changelog. D’autant plus qu’il existe des technologies qui nous permettent d’automatiser tout ça.

Quel format de nom ?

Git émet les mêmes contraintes pour le nom des tags que pour les autres formats de références comme les branches (voir git help check-ref-format pour plus de détail). On utilisera généralement des libellés alphanumériques, éventuellement contenant des slash / ou des tirets, sans espace.

Pour gérer tes versions logicielles, je te recommande de suivre la convention Semantic Versioning (qui n’est pas propre à Git).

Manipulation des tags

Outre la création des tags, on peut aussi les déplacer, les supprimer, les renommer.

Attention toutefois aux manipulations des tags partagés. Dès lors que tu partages un tag et qu’une partie de ton équipe le récupèrent, toute modification de ce tag ne sera pas transmise. Git considère qu’il ne doit pas changer un tag dans le dos de l’utilisateur. Tu peux alors choisir entre :

• utiliser un autre tag, admettant ainsi que tu as merdé ;
• prévenir tes collègues de ton erreur et leur demander de se synchroniser (suppression du tag localement et récupération explicite).

À toi donc de choisir la meilleure solution selon le contexte de ton projet.