Conventional Commits

Conventional Commits est une spécification (v1.0.0 formalisée 2019) qui standardise le format des messages de commit Git pour permettre l'automation (semantic-release, changelog generation, version bumping) et améliorer la lisibilité de l'historique. Adoptée massivement dans l'écosystème open source moderne.

Format : `<type>[optional scope]: <description>\n\n[optional body]\n\n[optional footer(s)]`

Types principaux : (1) feat: nouvelle fonctionnalité (MINOR bump) ; (2) fix: correction de bug (PATCH bump) ; (3) docs: documentation ; (4) style: formatage, espaces (no code change) ; (5) refactor: refactoring sans bug fix ni feature ; (6) perf: amélioration performance (PATCH) ; (7) test: ajout/correction tests ; (8) build: changement build system ou dependencies ; (9) ci: changement CI config ; (10) chore: maintenance générale (versions, configs) ; (11) revert: revert commit antérieur.

Breaking changes signalés via : (a) `!` après type/scope : `feat(api)!: remove deprecated endpoints` ; (b) footer `BREAKING CHANGE: <description>`. Triggers MAJOR bump.

Scopes : optional, désigne la zone du code modifiée (auth, api, ui, database, config). Ex: `feat(auth): add OAuth2 PKCE flow`.

Exemples :
- `fix(parser): handle empty array input` → PATCH bump (2.5.13 → 2.5.14)
- `feat(cli): add --watch flag for dev mode` → MINOR (2.5.13 → 2.6.0)
- `feat!: change API response format\n\nBREAKING CHANGE: response now wrapped in {data: ...}` → MAJOR (2.5.13 → 3.0.0)
- `docs(readme): fix typo in installation steps` → no version bump
- `chore(deps): bump axios from 1.4.0 to 1.6.0` → no bump unless breaking

Avantages : (1) automation versioning + changelog (semantic-release, release-please, standard-version, Changesets) ; (2) lisibilité historique (`git log --oneline` devient instructif) ; (3) collaboration claire (intent immédiate vs vague "updates" or "fix stuff") ; (4) facilite code review et PR title naming ; (5) outils tiers parseable (semantic-pull-requests action enforces in PR).

Enforcement tools : (1) commitlint — lint commit messages locally via husky pre-commit hook, OR in CI to reject non-conforming commits ; (2) commitizen — CLI interactive `git cz` pour guided commit prompts ; (3) Conventional PR — GitHub App enforcing PR titles follow convention ; (4) GitHub Actions semantic-pull-requests ; (5) Husky + lint-staged for full setup.

Monorepo considerations : utiliser scope pour identifier package (`feat(react-utils): add useDebounce hook`) — facilite per-package versioning via Changesets ou Lerna.

Deviation patterns acceptables : (1) gitmoji — préfixer commit avec emoji (✨ feat, 🐛 fix). Popular but less structured. (2) ChangelogD format. (3) Custom team conventions.

Integration with tools : Renovate utilise commit types pour grouper PRs (deps→chore, peer→feat); GitHub Actions semantic-release auto-detects types pour version bumps ; Changelogen générer changelogs ; PR comment bots citer related commits. Best for greenfield projects, gradual adoption possible.