infra / git-github
Tags et releases
Explication
Ce que vous allez apprendre
- Distinguer un tag léger d'un tag annoté et savoir lequel utiliser pour une version publiée
- Comprendre pourquoi
git pushne transmet jamais les tags par défaut - Créer une release GitHub à partir d'un tag, avec des notes de version lisibles
- Appliquer la convention SemVer (
MAJOR.MINOR.PATCH) pour nommer une version - Pousser, lister et supprimer des tags aussi bien en local que sur GitHub
Dans quel contexte ?
L'équipe de boutique-api vient de déployer en production une version jugée stable après plusieurs semaines de développement. Elle veut pouvoir dire précisément "voici le code exact qui tournait en production le 6 septembre 2026", sans avoir à retenir un identifiant de commit illisible comme a1b2c3d. Un tag v1.0.0, associé à une release GitHub avec des notes de version, répond exactement à ce besoin.
Certains commits comptent plus que d'autres
D'abord, parmi des milliers de commits, certains représentent un jalon particulier : la version exacte livrée à un client, la version déployée en production le jour du lancement.
Le problème d'un identifiant brut
Naviguer avec un identifiant de commit brut, une longue suite de caractères, pour retrouver ce moment serait peu pratique.
La solution : un nom mémorable et permanent
Un tag donne un nom mémorable et permanent à un commit précis, le plus souvent une version comme v1.0.0, pour pouvoir y revenir instantanément, même des années plus tard.
Deux types de tags, une vraie différence
Un tag "léger" n'est qu'un simple pointeur nommé, très basique. Un tag "annoté" est un objet Git complet, avec son propre auteur, sa date, son message.
Un avantage supplémentaire du tag annoté
Il offre surtout la possibilité d'être signé cryptographiquement, comme on le verra dans la dernière leçon sur la signature. Pour toute version publiée, le tag annoté est la pratique recommandée.
| Type de tag | Contient auteur/date/message ? | Peut être signé ? | Usage recommandé |
|---|---|---|---|
Léger (git tag v1.0.0) | Non | Non | Repère personnel rapide |
Annoté (git tag -a) | Oui | Oui | Toute version publiée |
Un piège fréquent : les tags ne suivent pas automatiquement
Une surprise classique pour qui découvre les tags : un simple git push ne transmet PAS les tags créés localement vers GitHub.
Ce qu'il faut faire à la place
Il faut le faire explicitement, un tag précis ou tous les tags d'un coup. Beaucoup de développeurs pensent avoir sauvegardé leur tag alors qu'il n'existe encore que sur leur machine.
Piège fréquent
Créer un tag v1.0.0 puis lancer un simple git push ne le transmet PAS à GitHub : le tag reste invisible pour le reste de l'équipe. Utilise systématiquement git push origin v1.0.0 (ou --tags pour tous) juste après la création d'un tag important.
Du tag à la release
Une release GitHub s'appuie sur un tag mais y ajoute une dimension "produit" : des notes de version lisibles pour des humains, et éventuellement des fichiers téléchargeables.
Un langage commun pour communiquer les versions
La convention de nommage SemVer, MAJOR.MINOR.PATCH, donne un langage commun pour communiquer, rien qu'avec le numéro de version, l'ampleur d'un changement.
La leçon suivante aborde un cas particulier : imbriquer un dépôt Git complet dans un autre, avec les sous-modules.
Commandes & code
Tags & releases GitHub
# Tag léger : juste un pointeur nommé vers un commit
git tag v1.0.0
git tag v1.0.0 a1b2c3d # tague un commit précis, pas forcément HEAD
# Tag annoté (recommandé) : objet Git complet avec auteur, date, message, signature possible
git tag -a v1.0.0 -m "Première version stable en production"
git show v1.0.0 # affiche les métadonnées du tag + le commit associégit tag # liste tous les tags
git tag -l "v1.1.*" # filtre par motif
# Pousser les tags vers GitHub (PAS automatique avec un simple "git push")
git push origin v1.0.0
git push origin --tags # pousse TOUS les tags locaux d'un coup
# Supprimer un tag
git tag -d v1.0.0
git push origin --delete v1.0.0# Créer une release GitHub depuis un tag, avec changelog et artefacts, via gh CLI
gh release create v1.0.0 \
--title "v1.0.0 - Première version stable" \
--notes "## Nouveautés\n- Authentification\n- Dashboard\n\n## Correctifs\n- Fix XSS #142" \
./dist/app-v1.0.0.tar.gz# Convention SemVer : MAJOR.MINOR.PATCH
# v1.0.0 -> v1.0.1 : correctif rétrocompatible (patch)
# v1.0.1 -> v1.1.0 : nouvelle fonctionnalité rétrocompatible (minor)
# v1.1.0 -> v2.0.0 : changement cassant l'API publique (major)
# Générer automatiquement des notes de release depuis les PR mergées
gh release create v1.1.0 --generate-notesRésumé
- Tag léger = pointeur simple ; tag annoté = objet complet (auteur, date, message, signature).
git pushne pousse PAS les tags par défaut :git push origin --tagsou un tag précis.- Une release GitHub s'appuie sur un tag et peut embarquer des artefacts binaires.
- SemVer (
MAJOR.MINOR.PATCH) donne une convention claire pour nommer les versions.
Exercices pratiques
Mission : publier une version traçable et signée
Objectif : Créer un tag annoté correctement poussé vers GitHub, et distinguer ce qui a réellement été partagé de ce qui est resté local.
Contexte
L'équipe de boutique-api vient de déployer une version stable en production. Un développeur crée un tag v1.0.0 avec git tag v1.0.0 puis fait un simple git push, persuadé d'avoir sauvegardé cette version pour toute l'équipe.