Workflow Git — workflow-inc-release-hotfix

Structure des branches

Branche	Rôle
main	Contient uniquement le code stable et versionné. Chaque commit sur main correspond à une version taggée (ex: v1.01 pour une release, v1.01.01 pour un hotfix).
dev	Branche de développement. Tous les travaux (features, fixes non critiques) y sont mergés avant validation pour main.

Convention de versionnage (incrémental pur)

Type	Format	Exemple	Description
majeurs	XX	1	XX = numéro incrémental de version majeurs
Release	XX.YY	1.01	YY = numéro de release dans la série XX.
Hotfix	XX.YY.ZZ	1.01.01	ZZ = numéro incrémental de hotfix pour la version XX.YY.

• Exemples :
  • 1.01 → 1re release de la version majeurs 1.
  • 1.02 → 2e release de la version majeurs 1.
  • 1.02.01 → 1er hotfix de la version 1.02.
  • 2.01 → 1re release de la version majeurs 2 (l'année suivante).

Numéro nu vs tag Git : le numéro XX.YY[.ZZ] ci-dessus est utilisé tel quel pour nommer les branches (release/1.02, hotfix/1.02.01), les messages de commit de merge, et le champ version des fichiers de projet (pyproject.toml, package.json, Cargo.toml...). Seul le tag Git réel est préfixé v (convention Git usuelle) : v1.02, v1.02.01. Ce préfixe est ajouté automatiquement par le hook post-merge — il n'y a rien à faire manuellement.

Règles clés

1. XX (version majeurs) :

   • Incrémenté manuellement une fois par an (ex: 1 pour 2026, 2 pour 2027).
   • Réinitialise YY à 01 à chaque nouvelle version majeurs.

2. YY (release) :

   • Incrémenté pour chaque release dans la version majeurs (ex: 1.01, 1.02, 1.03...).

3. ZZ (hotfix) :

   • Incrémenté uniquement pour les hotfix d'une version spécifique (ex: 1.01.01, 1.01.02...).
   • Ne pas réutiliser ZZ pour une même version XX.YY.

4. Tags :

   • Toujours annotés (git tag -a).
   • Toujours préfixés v (v1.02, v1.02.01).
   • Immuables : ne jamais modifier un tag poussé.
   • Créés automatiquement par le hook post-merge, avec un message par défaut ("release X.YY" ou "hotfix X.YY.ZZ") — pas d'édition interactive du message à la volée (voir automatisation.md pour le pourquoi).

Exemple visuel

main ────●───────────────●───────────────●───────────────●─────>
          |             /|              /|               |
       v1.01        v1.01.01        v1.01.02            v1.02
          |         /    |         /     |            /  |
dev ─────●────●───●──────●────●───●─────●────●──────●────●
          |   |          |               |               |
       feat/A feat/B   hotfix/1.01.01  feat/C       release/1.02

Résumé des bonnes pratiques

• Ne jamais travailler directement sur main.
• Toujours tester avant de merger dans dev ou main.
• Taguer systématiquement chaque version stable sur main (release ou hotfix), avec le préfixe v — automatique via post-merge.
• Documenter les changements dans les messages de commit.
• Garder dev à jour avec main après chaque release/hotfix — automatique via post-merge.
• Aucun commit intermédiaire requis sur release//hotfix/ avant de merger dans main : un merge où la branche est identique à dev (0 commit d'écart) fonctionne normalement — voir bugs_connus.md §2 pour l'historique de ce point.

Workflow du dépôt workflow-inc-release-hotfix de travail

Propager le fix : release du workflow lui-même

Comme ce dépôt suit son propre versionnement (déjà vu : v1.04, v1.05, v1.06.02...), on utilise un workflow normal :

cd ~/sources/workflow/workflow-inc-release-hotfix
git checkout dev
git pull origin dev
git add <fichiers modifier>
git commit -m "<Type>: <Description du commit"
git push origin dev

git checkout main
git pull origin main
VERSION=$(git-next-version <release ou hotfix>)   # ou hotfix, selon ta convention pour ce genre de correctif
git checkout -b <release ou hotfix>/$VERSION dev   # ou hotfix/$VERSION main, selon le choix
git checkout main
git merge --no-ff <release ou hotfix>/$VERSION    # ou hotfix/$VERSION
git push origin main
git push origin v$VERSION