Tags & Conventions de Release

Niveau : Intermediate

Durée : 1h30

Prérequis

Maîtriser les commits et l'historique Git
Savoir collaborer sur GitHub (Branches, Pull Requests)

Objectifs d'apprentissage

Comprendre l'utilité des tags pour identifier des versions logicielles
Maîtriser les principes du Semantic Versioning (SemVer)
Savoir créer des tags légers et annotés en local et les pousser sur GitHub
Rédiger des notes de release professionnelles en suivant les conventions de l'industrie

Progression dans cet atelier 0%

Slides PDF PPTX

1. Pourquoi utiliser des Tags ?

Dans un projet logiciel en production, l’historique Git s’enrichit rapidement de centaines ou de milliers de commits.

Imaginons la situation suivante :

Votre projet contient 1 200 commits.
Un utilisateur signale un bug critique sur la Version 1.3.0 déployée le mois dernier.
Le code actuellement sur la branche principale (main) a déjà beaucoup évolué et comporte 150 commits de plus.

Comment retrouver précisément l’état de votre code au moment de la livraison de la version 1.3.0 ?

C’est là qu’interviennent les Tags. Un tag (ou étiquette) est un repère fixe pointant vers un commit spécifique dans l’historique, lui associant un nom lisible et immuable (ex: v1.3.0).

gitGraph
    commit id: "Initial"
    commit id: "feat: auth"
    commit id: "feat: login" tag: "v1.0.0"
    commit id: "fix: validation"
    commit id: "feat: dashboard" tag: "v1.1.0"
    commit id: "fix: dashboard bug"

Avantages des tags :

Identification claire : Repérage instantané des versions majeures, mineures et correctifs.
Historique figé : Permet de revenir à tout moment à l’état exact du code d’une version donnée.
Automatisation : Déclenchement automatique de pipelines de CI/CD (ex: build et déploiement en production lors du push d’un tag de version).

2. Le Semantic Versioning (SemVer)

Pour nommer les versions de manière logique et compréhensible par tous (développeurs, utilisateurs, outils automatisés), l’industrie utilise la spécification du Semantic Versioning (ou versioning sémantique).

Une version est composée de trois nombres séparés par des points :

MAJOR.MINOR.PATCH  (ex: v1.4.2)

Par convention professionnelle, les numéros de version sont presque toujours préfixés par la lettre v (pour version). Cette convention est adoptée par les plus grands projets (Linux, Docker, Node.js, Kubernetes…).

Quand incrémenter chaque composant ?

Composant	Description	Exemple de modification
`MAJOR`	Modifications incompatibles (Breaking changes). Les utilisateurs de votre code doivent faire des modifications pour l’utiliser.	Refonte complète de la base de données, suppression de fonctions publiques d’une API.
`MINOR`	Nouvelles fonctionnalités compatibles avec les versions précédentes (Backward compatible).	Ajout d’une nouvelle page de dashboard, d’une nouvelle option de filtrage.
`PATCH`	Corrections de bugs compatibles avec les versions précédentes (Bug fixes).	Correction d’une faille de sécurité, ajustement CSS, correction d’une erreur de frappe.

3. Création et gestion de Tags avec Git

Il existe deux types de tags dans Git : les tags légers (lightweight) et les tags annotés (annotated).

Les tags légers (Lightweight)

C’est un simple pointeur vers un commit, similaire à une branche mais qui ne bouge pas. Il ne contient aucune information supplémentaire.

# Créer un tag léger
git tag v1.0.0

Les tags annotés (Annotated) — Recommandé

Les tags annotés sont stockés comme des objets complets dans la base de données Git. Ils contiennent le nom du créateur, la date, un message de description et peuvent être signés numériquement. C’est le standard professionnel pour les releases.

# Créer un tag annoté
git tag -a v1.0.0 -m "Initial Release - Première version stable de l'application"

Commandes utiles

Lister les tags existants dans le dépôt local :
Terminal window
```
git tag
```
Afficher les détails d’un tag (créateur, date, message et le commit associé) :
Terminal window
```
git show v1.0.0
```
Pousser un tag spécifique sur GitHub (car un simple git push n’envoie pas les tags) :
Terminal window
```
git push origin v1.0.0
```
Pousser tous les tags locaux d’un coup :
Terminal window
```
git push origin --tags
```

Supprimer un tag local et distant :

# Supprimer en local
git tag -d v1.0.0
# Supprimer sur le dépôt distant (GitHub)
git push origin --delete v1.0.0

4. Conventions de Release et Changelog

Sur GitHub, une Release (ou publication) est construite par-dessus un tag Git. Elle fournit un livrable clair (code source compressé, binaires compilés) et une documentation lisible par les humains décrivant les changements.

La structure professionnelle d’une Release (Keep a Changelog)

Pour que vos notes de release soient professionnelles, vous devez catégoriser vos modifications selon les sections standards :

Added : Pour les nouvelles fonctionnalités introduites.
Changed : Pour les modifications apportées à des fonctionnalités existantes.
Fixed : Pour les corrections de bugs.
Security : Pour les corrections concernant des failles de sécurité.
Deprecated : Pour les fonctionnalités obsolètes qui seront supprimées dans les prochaines versions majeures.
Removed : Pour les fonctionnalités définitivement supprimées.

Exemple de note de Release GitHub :

# v1.2.0 - Notifications Release

Date de publication : 2026-06-21

## Added
- Intégration du système de notifications en temps réel par Email
- Ajout d'un centre de notifications dans le menu principal

## Changed
- Amélioration des performances de chargement du Dashboard (temps de réponse réduit de 40%)

## Fixed
- Résolution d'un bug de boucle de redirection lors de la connexion OAuth
- Correction de l'affichage du menu sur les écrans mobiles (responsive)

## Security
- Limitation du nombre de requêtes sur les endpoints sensibles (Rate Limiting)

Fiches de révision

Question

Quelle est la structure du Semantic Versioning ?

Cliquer pour révéler la réponse

Réponse

MAJOR.MINOR.PATCH (ex: v1.0.0)

Cliquer pour voir la question

Question

Dans quel cas incrémente-t-on le numéro MAJOR ?

Cliquer pour révéler la réponse

Réponse

Lorsqu'on introduit des changements incompatibles avec les versions précédentes (breaking changes).

Cliquer pour voir la question

Question

Quelle commande Git permet de créer un tag annoté de version ?

Cliquer pour révéler la réponse

Réponse

git tag -a v1.0.0 -m 'Description'

Cliquer pour voir la question

Question

Pourquoi faut-il exécuter git push origin --tags ?

Cliquer pour révéler la réponse

Réponse

Parce qu'un git push classique n'envoie pas les tags locaux vers le dépôt distant.

Cliquer pour voir la question

Quiz de validation

1. Si vous ajoutez une nouvelle fonctionnalité qui ne casse pas la compatibilité de l'application, quelle version incrémentez-vous à partir de v1.2.3 ?

2. Quelle est la différence essentielle entre un tag léger et un tag annoté ?

3. Sous quelle catégorie de release devez-vous répertorier la correction d'une faille de sécurité ?

Prochaine étape

Vous maîtrisez à présent le versioning de vos projets et la rédaction de releases claires. Poursuivons en découvrant comment structurer et administrer le travail de collaboration à grande échelle au sein d’une organisation professionnelle sur GitHub !

Prochain atelier

14. GitHub Organizations

Labs associés

Lab Niveau 15 — Tags & Releases