Azmog b49b2f172f feat: mise en place du workflow GitFlow et du versioning par tags (commitizen)

- Ajout de cz.toml portant le numero de version du projet (0.1.0)
- Documentation du process de dev GitFlow sans hotfix (CONTRIBUTING.md)
- main/develop/feature/release, releases taguees via 'cz bump'

2026-06-16 16:27:32 +02:00

3.4 KiB

Raw Blame History

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) :

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.

3. Cycle d'une fonctionnalité (`feature/*`)

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

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

3.4 KiB Raw Blame History