« Fix truc », « maj test »... Vous aussi, vous vous demandez parfois ce que vous vouliez dire il y a trois semaines ? Ou vous tombez sur un « some updates » sans vraiment savoir ce qui a changé ?
Les commits conventionnels (ou conventional commits) s’inscrivent dans une logique d’intégration continue et posent un cadre simple pour écrire des messages clairs et explicites. Voici un apperçu rapide de son fonctionnement.
Qu'est-ce qu'un commit conventionnel ?
C'est un format de message de commit structuré, qui suit une syntaxe précise. L'idée est de décrire clairement le type de changement apporté dans le code. Voici la structure de base :
type(scope): description courte
-
type: la nature du changement (ex :feat,fix,docs,refactor, etc.) -
scope(optionnel) : la partie du code concernée (ex :auth,api,ui) -
description: une phrase concise à l'impératif -
!(en suffixe du type) : indique un changement majeur (breaking change)
Exemples :
feat(api): add account creation endpoint
fix(ui): fix misaligned submit button in mobile registration form
docs: update README with installation instructions
feat!: remove deprecated /login endpoint
Pourquoi utiliser les commits conventionnels ?
Adopter cette convention apporte de nombreux bénéfices :
- Clarté de l'historique Git : plus facile de comprendre les changements
- Génération automatique de changelogs : avec des outils comme semantic-release
- Versioning sémantique facilité : les types de commits permettent de déduire les changements de version (MAJOR, MINOR, PATCH)
Les types les plus courants
Voici quelques types standard que vous pouvez utiliser :
-
feat: ajout d'une fonctionnalité -
fix: correction de bug -
docs: documentation uniquement -
style: mise en forme, indentation, etc. (sans impact sur le code, rien à voir avec le CSS) -
refactor: modification du code sans ajout de fonctionnalité ni correction de bug -
test: ajout ou modification de tests -
chore: tâches diverses (ex : MAJ de dépendances)
L'objectif final : l'automatisation des versions
Une fois vos messages de commit structurés, vous pouvez aller encore plus loin : automatiser la gestion des versions.
Certains outils comme semantic-release permettent de déterminer automatiquement les numéros de version à partir des types de commit, de mettre à jour le changelog, de créer un tag Git et de publier la version, le tout sans intervention manuelle.
Un gain de temps, de rigueur, et de la charge mentale en moins!
Quelques outils pour faciliter son utilisation
Vous retrouverez:
- La spécification officielle des commits conventionnels : pour comprendre la syntaxe en détail
- Cet article de Eleven Labs : un bon complément pour découvrir plus en profondeur
semantic-releaseet l'automatisation des versions
Pour vous aider à mettre en place les commits conventionnels, plusieurs outils existent :
- Commitizen (cz-cli) : pour créer des commits via une interface interactive guidée
- commitlint : pour vérifier que les messages de commit respectent la convention
- Husky : pour intégrer des vérifications (comme commitlint) en pré-commit
Top comments (0)