# 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.