Aller au contenu

ADR-001 (dev) — Gitflow complet + Commitizen + SemVer automatisé

Statut : accepté (2026-07-19)

Contexte

Les projets de dev (portfolio, futures apps) ont besoin d'une convention de branches, de commits et de versions commune, appliquée dès la création d'un projet, pour éviter que chaque repo invente la sienne.

Décision

  • Gitflow complet, outillé par git-flow (AVH Edition, licence BSD) : main + develop permanentes, feature/*, release/*, hotfix/* pilotées par les commandes git flow — cf. conventions.
  • Conventional Commits écrits avec Commitizen (cz commit, licence MIT) et vérifiés en CI.
  • SemVer calculé et tagué automatiquement par la CI sur main (cz bump : tag + changelog). Pour éviter le double tag, git flow release/hotfix finish est configuré sans tag (finish.notag true) : git-flow gère les branches, la CI gère les versions.

Justification

  • Alternative considérée : flux simplifié (main + feature branches), moins cérémonieux et objectivement suffisant pour un dev solo en déploiement continu. Écartée par choix assumé : je veux pratiquer Gitflow (compétence répandue en entreprise, valorisable en entretien) et garder un modèle qui tiendra si un projet accueille d'autres contributeurs.
  • Commitizen plutôt que semantic-release : un seul outil couvre l'assistance au commit, la vérification et le bump ; sans dépendance à Node.js, il s'applique à des projets de toute stack.
  • Tags posés par la CI et non à la main : le numéro de version reflète mécaniquement le contenu réel des commits.

Conséquences

  • Toute feature passe par une PR vers develop ; main n'avance que par release ou hotfix. En solo, c'est un coût de cérémonie accepté.
  • La qualité du changelog dépend de la qualité des messages de commit (vérifiés en CI, mais la description reste humaine).
  • La CI pousse sur main (tag + changelog) : elle détient un token Forgejo (secret Woodpecker forgejo_token, scope repository).
  • L'infra (infra, docs) reste en trunk-based : cet ADR ne s'y applique pas.