merge: integration de feature/tags dans develop

site/CONTRIBUTING.md

@@ -0,0 +1,86 @@
+# Process de développement — GitFlow (sans hotfix)
+
+Ce projet suit une variante de **GitFlow** sans branches *hotfix*, avec des
+commits conventionnels et un versionnage automatique géré par **commitizen** (`cz`).
+
+## 1. Les branches
+
+| Branche      | Rôle                                                        | Durée de vie |
+|--------------|-------------------------------------------------------------|--------------|
+| `main`       | Code en **production**. Chaque commit = une version taguée. | permanente   |
+| `develop`    | Branche d'**intégration**. Reçoit les features terminées.   | permanente   |
+| `feature/*`  | Développement d'une fonctionnalité. Part de `develop`.      | temporaire   |
+| `release/*`  | Préparation d'une **version (tag)**. Part de `develop`.     | temporaire   |
+
+> Pas de branche `hotfix` : les correctifs urgents passent par une `feature/*`
+> classique (ou directement par une `release/*` si déjà en cours).
+
+```
+main     ●────────────────────────●──────────────● (v0.1.0)   (v0.2.0)
+          \                      /                /
+develop    ●──●──●──────●──────●────●──●────────●
+               \      /             \          /
+feature/*       ●──●●               ●──●──●  (release/0.2.0)
+```
+
+## 2. Outils
+
+Installation de commitizen (une seule fois) :
+
+```bash
+pip3 install --user commitizen      # fournit la commande `cz`
+cz version                          # ou : python3 -m commitizen version
+```
+
+Le **numéro de version** du projet est stocké dans [`cz.toml`](./cz.toml).
+
+## 3. Cycle d'une fonctionnalité (`feature/*`)
+
+```bash
+# 1. Créer la branche depuis develop
+git switch develop
+git switch -c feature/ma-fonctionnalite
+
+# 2. Coder, puis committer avec commitizen (commits conventionnels)
+cz commit            # alias : cz c  — assistant interactif (type, scope, message)
+
+# 3. Pousser
+git push -u origin feature/ma-fonctionnalite
+
+# 4. Fusionner dans develop (via Merge Request, ou en local)
+git switch develop
+git merge --no-ff feature/ma-fonctionnalite
+git branch -d feature/ma-fonctionnalite
+```
+
+### Types de commits conventionnels (impactent la version)
+- `feat:` → nouvelle fonctionnalité → incrémente le **MINEUR** (0.1.0 → 0.2.0)
+- `fix:`  → correction de bug → incrémente le **CORRECTIF** (0.1.0 → 0.1.1)
+- `feat!:` ou `BREAKING CHANGE:` → incrémente le **MAJEUR** (0.x → 1.0.0)
+- `docs:`, `chore:`, `refactor:`, `test:`, `style:`, `ci:` → pas de bump
+
+## 4. Cycle d'une release (branche de tag)
+
+La création d'un tag de version se fait via une branche `release/*` et `cz bump`.
+
+```bash
+# 1. Créer la branche de release depuis develop
+git switch develop
+git switch -c release/x.y.z
+
+# 2. Calculer la nouvelle version + créer le tag + MAJ CHANGELOG.md
+#    (cz lit cz.toml, déduit la version depuis les commits, met à jour le fichier)
+cz bump                       # ajoute aussi un commit "bump: version X -> Y" et le tag vX.Y.Z
+
+# 3. Fusionner la release dans main ET dans develop
+git switch main
+git merge --no-ff release/x.y.z
+git switch develop
+git merge --no-ff release/x.y.z
+git branch -d release/x.y.z
+
+# 4. Pousser branches + tags
+git push origin main develop --follow-tags
+```
+
+> `cz bump --dry-run` permet de prévisualiser la prochaine version sans rien modifier.

site/cz.toml

@@ -0,0 +1,13 @@
+# Configuration du versioning du projet (commitizen / "gitcz")
+# C'est ce fichier qui porte le NUMÉRO DE VERSION du projet.
+# `cz bump` lit/incrémente automatiquement la valeur `version` ci-dessous
+# en fonction des commits conventionnels, puis crée le tag git correspondant.
+[tool.commitizen]
+name = "cz_conventional_commits"   # Type de commits : Conventional Commits (feat:, fix:, ...)
+version = "0.1.0"                   # <== NUMÉRO DE VERSION du projet
+version_scheme = "semver"          # Versionnage sémantique MAJEUR.MINEUR.CORRECTIF
+tag_format = "v$version"           # Format des tags de release : v0.1.0, v0.2.0, ...
+major_version_zero = true          # Tant que la version commence par 0.x, pas de passage en 1.0 automatique
+update_changelog_on_bump = true    # Met à jour CHANGELOG.md à chaque release
+changelog_incremental = true
+annotated_tag = true               # Tags annotés (recommandé pour les releases)