Construisez un message Conventional Commit
Les Conventional Commits sont un format pour les messages git qui transforme le chaos (« update », « fix stuff », « wip ») en un historique lisible. Chaque commit commence par un type (`feat`, `fix`, `docs`, `refactor`...), a éventuellement un scope entre parenthèses (par exemple `feat(auth):`), puis une courte description. Facile à lire, facile à automatiser.
Cet outil assemble un message de commit depuis un formulaire. Choisissez un type dans la barre (11 types), tapez la description courte, ajoutez éventuellement un scope, un corps, un breaking change (ajoute `!` après le type et un footer `BREAKING CHANGE:`), des footers (Closes #123, Co-authored-by, Signed-off-by).
Vous obtenez le résultat en trois formats : texte brut (à coller dans l'éditeur après `git commit`), commande shell (`git commit -m "..."` avec guillemets échappés), JSON (pour les bots comme semantic-release).
Validation en direct : description courte de 72 caractères max (limite stricte), pas de point final, présent (« add » et non « added »).
Mode d'emploi
- Choisissez un type de commit dans la barre du haut. feat (nouvelle fonctionnalité), fix (correction de bug), docs (documentation), refactor (changement de code sans changement de comportement), perf (performance), test, build, ci, chore (petit ménage), revert, style (mise en forme).
- Scope (optionnel) : la partie du code que le commit touche, par exemple `auth`, `api`, `ui`. Cliquez sur une pastille preset ou tapez la vôtre. Elle apparaît entre parenthèses : `feat(auth): ...`.
- Description courte : une ligne, 72 caractères max, pas de point final, au présent (« add login flow », pas « added login flow »). Le compteur affiche la longueur, alerte au-delà de la limite et quand il repère du passé.
- Breaking change (Switch) : activez si ce commit casse la rétrocompatibilité (changement d'API, fonctionnalité retirée, changement de sémantique). Le générateur ajoute `!` après le type (`feat!:`) et un footer `BREAKING CHANGE: description`.
- Body (optionnel) : les détails. Écrivez pourquoi ici (contexte, motivation), pas quoi (le diff le montre déjà).
- Footers (optionnel) : ajoutez des lignes avec les boutons. Closes #123 (clôt une issue), Refs #456 (issue liée, sans clôture), Co-authored-by (un second auteur, par exemple après du pair programming), Signed-off-by (DCO, Developer Certificate of Origin, exigé par des projets comme le noyau Linux), Reviewed-by, Custom (votre propre clé).
- Choisissez le format de sortie (Plain / Shell / JSON) et copiez. Plain part dans l'éditeur git après `git commit`. Shell va directement dans le terminal. JSON alimente un bot CI ou un générateur de changelog.
Quand c'est utile
Situations concrètes où Conventional Commits change la qualité d'un projet :
- Releases automatiques. semantic-release ou release-please analysent les commits depuis la dernière release. feat → bump minor (1.4.0 → 1.5.0). fix → bump patch (1.4.0 → 1.4.1). BREAKING CHANGE → bump major (1.4.0 → 2.0.0). Zéro travail manuel.
- CHANGELOG.md automatique. Après une release, l'outil génère une section « What's new in 1.5.0 », groupée en « Features », « Bug Fixes », « Performance Improvements ». Chaque ligne pointe vers le commit. Vous pouvez aussi le faire à la main avec notre générateur de changelog.
- Historique git lisible. `git log --oneline` affiche « feat(auth): add magic link login », « fix(api): handle empty body », « docs: clarify install steps ». Pas « update », « fix », « wip ». Tout nouvel équipier comprend l'historique d'un coup d'œil.
- Revue de code plus rapide. Le relecteur voit le préfixe et sait s'il s'agit d'un feat (regarder de près les tests, les edge cases) ou d'un refactor (regarder de près, le comportement ne doit pas avoir changé). Il peut filtrer les PR par type.
- Templates de PR et vérifications CI. Beaucoup de projets (Vercel, Astro, Next.js) ont une validation CI qui vérifie que le titre de PR est un Conventional Commit. Générez un titre valide ici pour que le bot ne vous rejette pas.
- Travail dans un monorepo. Le scope dans le commit (`feat(web):`, `fix(api):`) indique dans quel package/app le changement se trouve. Les changelogs les groupent séparément.
Après avoir produit un lot de commits, utilisez le générateur de CHANGELOG qui groupe les commits par type. Et si vous construisez un README de projet, la section « Contributing » est un bon endroit pour mentionner Conventional Commits, le générateur de README a un template prêt.