Comment fonctionnent les tags et les releases dans Git ?

Question

Accepted Answer

**Les tags** marquent des points spécifiques de l'historique comme importants — typiquement des **releases** (versions comme v1.0.0). Contrairement aux branches, les tags sont des pointeurs fixes qui ne bougent pas, utilisés pour étiqueter et référencer les versions de release. Ils sont centraux dans la gestion des versions et des releases.

## Créer des tags

```bash
# annotated tag (recommended for releases — has metadata: tagger, date, message)
git tag -a v1.0.0 -m "Release version 1.0.0"

# lightweight tag (just a pointer, no metadata)
git tag v1.0.0

# tag a specific past commit
git tag -a v1.0.0 <commit> -m "..."
```

**Les tags annotés** (recommandés pour les releases) stockent des métadonnées (auteur du tag, date, message) ; **les tags légers** sont simplement un nom pointant vers un commit.

## Travailler avec les tags

```bash
git tag                        # list tags
git show v1.0.0                # show a tag and its commit
git checkout v1.0.0            # check out the code at a tag (detached HEAD)

# tags are NOT pushed by default — push them explicitly:
git push origin v1.0.0         # push a specific tag
git push origin --tags         # push all tags
```

Important : **les tags ne sont pas poussés automatiquement** avec `git push` — vous devez les pousser explicitement.

## Tags vs branches

```text
BRANCH → a MOVABLE pointer that advances as you commit (ongoing development)
TAG    → a FIXED pointer to a specific commit (a permanent label — doesn't move)
→ Use tags to permanently mark releases/milestones; branches for ongoing work.
```

## Versioning sémantique et releases

```text
SEMANTIC VERSIONING (SemVer): MAJOR.MINOR.PATCH (e.g. v2.3.1)
  MAJOR → breaking changes | MINOR → new features (compatible) | PATCH → bug fixes
→ Tags label these versions. Platforms (GitHub) build "Releases" from tags
  (with release notes, built artifacts) for distribution.
```

## Pourquoi c'est important

Comprendre les tags et les releases est précieux pour la **gestion des versions et des releases**, c'est donc une connaissance pratique utile pour travailler avec des logiciels livrés. **Les tags** marquent des points importants de l'historique — typiquement des **versions de release** (comme v1.0.0) — fournissant des références fixes et permanentes à des commits spécifiques, ce qui est essentiel pour suivre et référencer quel code constitue chaque release.

Comprendre la distinction entre **les tags annotés** (recommandés pour les releases, stockant des métadonnées comme l'auteur du tag, la date et le message) et les tags légers est une connaissance pratique pour un tagging approprié des releases.

Savoir comment créer, lister et consulter les tags, et surtout que **les tags ne sont pas poussés automatiquement** (nécessitant un `git push origin --tags` explicite ou la poussée de tags spécifiques — une erreur courante où les gens créent des tags mais oublient de les pousser), est nécessaire pour gérer correctement les tags de release.

Comprendre **les tags vs branches** (un tag est un pointeur fixe vers un commit spécifique — une étiquette permanente qui ne bouge pas — tandis qu'une branche est un pointeur mobile qui avance avec le développement) clarifie leurs rôles différents : les tags pour marquer de manière permanente les releases/jalons, les branches pour le travail en cours.

Comprendre la connexion avec le **versioning sémantique** (conventions MAJOR.MINOR.PATCH pour communiquer la nature des changements) et comment les plateformes construisent des **Releases** à partir de tags (avec des notes de release et des artefacts pour la distribution) reflète comment les tags s'intègrent dans la gestion réelle des releases.

Puisque la publication et le versioning de logiciels sont un besoin courant et que les tags sont le mécanisme Git pour marquer et référencer les versions de release (centraux à la gestion des releases et intégrés aux fonctionnalités de release des plateformes), comprendre les tags et les releases — tags annotés vs tags légers, les pousser, tags vs branches, et leur rôle dans le versioning/les releases — est une connaissance Git précieuse et pratiquement pertinente pour gérer les logiciels livrés, un aspect utile du développement professionnel connecté aux conventions de versioning et aux processus de release.