Conventional Commits et commitlint : Un nouveau standard pour rédiger des messages de commit

vendredi 10 janvier 2025

Les messages de commit, plus importants qu'on ne le pense

Lorsqu'on est développeur, on écrit souvent plusieurs messages de commit en une seule journée. Chaque fois, on a cette idée vague qu'il faut bien résumer les changements effectués dans le code, mais il n'est pas facile de parvenir à une synthèse précise, et on finit souvent par rédiger des messages obscurs.

En réalité, les messages de commit jouent un rôle plus crucial plus tard, lorsqu'on revient sur le code longtemps après, ou lorsqu'il faut relire le code conçu par un collègue. Un bon message de commit est un atout précieux dans ces situations.

En fin de compte, bien rédiger un message de commit est une sorte d'assurance qui accroît la productivité à long terme de l'équipe et facilite le débogage. Malheureusement, sans conventions ou contraintes définies, il est aussi difficile de rédiger des messages cohérents et clairs que de trouver un bon nom de variable.

Conventional Commits

C'est alors que j'ai découvert Conventional Commits. Cette convention propose quelques types de changements préétablis et prescrit de décrire la portée et le sujet des modifications.

Bien que simples, ces règles permettent d'écrire des messages de commit plus uniformes et standardisés, et elles s'intègrent avec Semantic Versioning, ce qui s'avère être un atout précieux pour la productivité.

Les règles de base sont les suivantes.

Règles de base

  1. Format : Suivez le format type(scope): subject.

    • type: Type de changement (par exemple : feat, fix, docs, style, refactor, test, etc.).
    • scope (optionnel) : Portée ou module affecté par le changement.
    • subject : Description concise des changements.
  2. Corps : Ajoutez des explications supplémentaires sur le changement si nécessaire.

  3. Exemples :

feat(auth): add user login functionality
fix(api): resolve null pointer exception in fetch method
docs: update readme with installation instructions

Ce format est lié au Semantic Versioning de la manière suivante :

Lorsqu'un projet utilise Semantic Versioning, vous pouvez gérer automatiquement les versions uniquement grâce aux messages de commit. Par exemple :

  • feat(auth): add user login functionality → ajout de fonctionnalité 👉 v1.1.0
  • fix(api): resolve null pointer exception → correction de bug 👉 v1.1.1
  • feat(payment): add credit card support → autre fonctionnalité ajoutée 👉 v1.2.0

En résumé, les Conventional Commits offrent plusieurs avantages :

  • Cohérence : Des messages cohérents rendent l'historique des projets facile à comprendre.
  • Intégration avec les outils automatisés : Génération de notes de version, intégration avec les pipelines CI/CD, etc.
  • Efficacité des code reviews : Compréhension rapide de l'intention des changements pour des revues efficaces.
  • Amélioration de la scalabilité : Même avec la croissance du projet, la maintenance reste aisée grâce à des messages de commit uniformes.

Et il y a même un lint : (commitlint)

Les principales fonctions de commitlint sont les suivantes :

  1. Validation des Conventional Commits : Vérifie que le message suit le format type(scope): subject.
  2. Personnalisable : Offrez la possibilité d'ajouter ou de modifier des règles selon les besoins de votre équipe.
  3. Intégration CI/CD : Intégrez commitlint à votre pipeline pour valider les commits.
  4. Intégration avec Husky : Utilisation de Git hooks pour vérifier automatiquement les messages de commit.

En règle générale, il est assez simple d'appliquer commitlint à un projet et d'en tirer de nombreux avantages. Si votre équipe adhère aux Conventional Commits, il est également recommandé d'adopter commitlint pour uniformiser la pratique. Pour plus de détails, consultez le site officiel de commitlint.

Bien sûr, on peut toujours écrire de bons messages de commit sans l'aide d'un lint, mais les erreurs humaines sont possibles. Un ensemble de commits mal formulés finit par créer une confusion qui nuit au projet.

De plus, il est bien plus productif de râler contre un ordinateur qui bloque un mauvais message de commit que de donner un feedback à un collègue à ce sujet.

Des messages de commit cohérents, un premier pas vers une productivité d'équipe accrue

Les messages de commit ne sont pas de simples enregistrements de changements; ils organisent l'historique d'un projet et facilitent la collaboration fluide entre les membres d'une équipe. En particulier, lorsque plusieurs développeurs travaillent ensemble, des messages de commit cohérents facilitent les reviews de code et la compréhension des modifications.

Appliquer des règles cohérentes au niveau individuel permet de réduire les hésitations et d'écrire des messages clairs, tandis qu'en utilisant des outils comme commitlint, on prévient automatiquement les erreurs et on rationalise l'intégration avec CI/CD.

Pourquoi ne pas adopter la bonne habitude d'appliquer des règles précises aux commits pour rédiger des messages cohérents? Cela peut sembler contraignant au début, mais avec le temps, cela augmentera considérablement la productivité de l'équipe.