Tags Git, versions et CHANGELOG

Un tag Git est une étiquette permanente posée sur un commit pour marquer une version livrée, par exemple v1.2.0. Associé au versionnage sémantique (SemVer), à un fichier CHANGELOG et aux releases de GitHub, il permet de savoir à tout moment quelle version tourne, ce qu'elle contient et comment y revenir. Ce chapitre montre comment créer et pousser des tags, numéroter ses versions, tenir un CHANGELOG, publier une release, puis signer ses commits et ses tags avec une clé SSH ou GPG.

Créer un tag

Une branche avance à chaque commit ; un tag reste toujours sur le même commit. Il existe deux sortes de tags :

Pour une version, utilise toujours un tag annoté : il dit qui a livré, quand et pourquoi. Les tags légers servent de marque-pages personnels.

git tag -a v1.0.0 -m "Version 1.0.0 : saisie et validation des notes de frais"
git tag -a v0.9.0 -m "Version de démonstration" 4e0f9a2   # sur un commit plus ancien

Pousser les tags

git push n'envoie pas les tags. Pousse-les explicitement :

git push origin v1.0.0      # un tag
git push origin --tags      # tous les tags locaux

git push --follow-tags pousse les commits et les tags annotés qui les accompagnent ; git config --global push.followTags true en fait le comportement par défaut.

Le versionnage sémantique (SemVer)

Le versionnage sémantique (Semantic Versioning, SemVer 2.0.0) donne un sens à chaque chiffre d'un numéro de version MAJEUR.MINEUR.CORRECTIF :

Quand un chiffre augmente, ceux qui sont à sa droite reviennent à 0. D'autres règles :

• tant que la version majeure vaut 0 (0.3.1), tout peut changer à tout moment : le logiciel est en développement initial ;
• 1.0.0 est la première version stable, celle dont tu garantis la compatibilité ;
• une préversion s'écrit avec un tiret : 2.0.0-beta.1, 2.0.0-rc.1 ; elle est considérée comme antérieure à 2.0.0 ;
• le v des tags (v1.0.0) est une convention de Git, pas une partie du numéro SemVer.

Les gestionnaires de dépendances s'appuient sur ces règles. Dans un package.json, "express": "^5.1.0" accepte toute version 5.x.y à partir de 5.1.0 mais pas 6.0.0, parce qu'une version majeure peut casser ton code ; ~5.1.0 n'accepte que les correctifs 5.1.y.

Tenir un CHANGELOG

Un CHANGELOG est un fichier, CHANGELOG.md à la racine du dépôt, qui liste pour chaque version les changements notables, écrits pour des humains. Ce n'est pas une copie du git log : on regroupe, on reformule, on omet les détails internes. Le format le plus répandu est celui de Keep a Changelog :

# Changelog

Les changements notables de Sorbier Frais sont listés dans ce fichier.
Format : Keep a Changelog. Numérotation : versionnage sémantique.

## [Non publié]
### Ajouté
- Duplication d'une note de frais.

## [1.1.0] - 2026-11-20
### Ajouté
- Export CSV des notes validées, pour la comptabilité (#18).
### Corrigé
- Le filtre par mois oubliait les notes du dernier jour du mois (#12).

## [1.0.0] - 2026-10-30
### Ajouté
- Saisie, envoi et validation des notes de frais.
- Connexion par compte, rôles salarié et comptable.

Les rubriques possibles : Ajouté, Modifié, Obsolète, Supprimé, Corrigé, Sécurité. La section Non publié accumule les changements au fil des pull requests ; au moment de livrer, elle devient la nouvelle version, datée.

À l'E6, le CHANGELOG est une preuve directe de l'indicateur « une documentation des versions accompagne l'intégration » : la commission y lit ce que contient chaque version et pourquoi (préparer son dépôt).

Publier une release sur GitHub

Une release GitHub est une page de version associée à un tag : titre, notes de version, et fichiers téléchargeables (l'installeur d'une application de bureau, une archive prête à déployer). GitHub ajoute automatiquement les archives du code source.

Dans l'onglet Releases, Draft a new release : choisis le tag (ou crée-le), écris le titre « Version 1.1.0 », colle la section du CHANGELOG ou clique sur Generate release notes, qui liste les pull requests fusionnées depuis la version précédente. Avec GitHub CLI :

gh release create v1.1.0 --title "Version 1.1.0" --notes-file notes-1.1.0.md
gh release create v1.1.0 ./publish/SorbierFrais-1.1.0.zip --generate-notes   # avec un fichier joint

Pour un client lourd C# (WinForms, WPF), la release est l'endroit naturel où déposer l'exécutable publié, au lieu de le versionner dans le dépôt : le dépôt contient le code, la release contient le livrable.

Signer ses commits et ses tags

N'importe qui peut écrire git config user.name "Lina Morel" et commiter sous ce nom : Git ne vérifie pas l'identité de l'auteur. La signature des commits règle ce problème. Chaque commit signé porte une signature faite avec ta clé privée, que GitHub vérifie avec ta clé publique et marque d'un badge Verified.

La façon la plus simple de signer est d'utiliser ta clé SSH, la même que pour te connecter ou une clé dédiée :

git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true    # signer tous les commits
git config --global tag.gpgsign true       # signer tous les tags annotés

Sur GitHub, ajoute la clé publique une seconde fois dans Settings, SSH and GPG keys, en choisissant le type Signing Key (une clé déclarée comme clé d'authentification ne sert pas à vérifier les signatures). Tes prochains commits afficheront Verified.

L'autre méthode, plus ancienne, utilise une clé GPG (OpenPGP) : gpg --full-generate-key, puis git config --global user.signingkey <identifiant-de-la-clé> et la clé publique exportée avec gpg --armor --export dans les réglages de GitHub.

Exercices

## [1.2.0] - 2027-01-15
### Ajouté
- Duplication d'une note de frais (#25).
### Corrigé
- Le total d'une note inclut désormais les frais de péage (#27).
### Sécurité
- Un utilisateur ne peut plus supprimer la note d'un autre utilisateur (#29).