Conventional Commit

Fri, 08 May 2026 08:00:00 +0200

Je démarre ici une nouvelle série d’articles sur les bonnes pratiques de développement, en commençant par une convention de commit que j’utilise au quotidien.

Introduction

Conventional Commit est une convention pour formater les messages de commit de manière structurée et standardisée. Elle permet de faciliter la lecture et la compréhension des messages de commit, ainsi que d’automatiser certaines tâches comme la génération de changelogs ou la gestion des versions.

Exemple de commit suivant la convention Conventional Commit

feat: add new feature X
fix: correct bug Y

Dans cet exemple, feat indique qu’il s’agit d’une nouvelle fonctionnalité, tandis que fix indique qu’il s’agit d’une correction de bug.

Pourquoi choisir Conventional Commit ?

Conventional est l’une si ce n’est la seule convention de commit largement utilisée dans la communauté open source et dans l’industrie. Elle est supportée par de nombreux outils et intégrations, ce qui en fait un choix populaire pour les projets de toutes tailles.

Quelques exemples d’acteurs majeurs qui utilisent Conventional Commit :

En pratique

Les types de commit possibles

Voici quelques types standard que j’utilise au quotidien dans mes projets (trier par ordre d’utilisation) :

feat : ajout d’une fonctionnalité
fix : correction de bug
chore : tâches diverses (ex : MAJ de dépendances)
docs : documentation uniquement
refactor : modification du code sans ajout de fonctionnalité ni correction de bug
test : ajout ou modification de tests

Le scope

Il est également possible d’ajouter un scope pour préciser la partie du code concernée par le commit.

Par exemple : feat(auth): add login functionality

Dans cet exemple, auth est le scope qui indique que le commit concerne la partie d’authentification du projet.

Bonnes pratiques

Utiliser des verbes à l’infinitif (ex : “add”, “fix”, “update”, etc.)
Ne pas dépasser 72 caractères pour la ligne de titre du commit
Ajouter une description plus détaillée dans le corps du commit si nécessaire
Utiliser des préfixes pour indiquer les types de commit (ex : “feat:”, “fix:”, etc.)

Un pas vers l’automatisation

Les conventional commits sont la première étape vers une chaîne de CI/CD plus automatisée. En utilisant des messages de commit structurés, il devient possible d’automatiser la génération de changelogs, la gestion des versions et même le déploiement en production.

Workflow CI/CD avec Conventional Commit

  flowchart TD
    A[Développement] --> B[Conventional Commit]
    B --> C[CI/CD]
    C --> D[Tests automatiques]
    D --> E{Tests réussis ?}
    E -- Oui --> F[Génération Changelog + Versioning]
    E -- Non --> H[Correction du code et nouveau commit]
    F --> I{Déploiement ?}
    I -- Version mineur ou patch --> J[Déploiement automatique]
    I -- Version majeure --> K[Déploiement manuel]

Stratégie de versioning

En utilisant les types de commit, il est possible d’adopter une stratégie de versioning sémantique (SemVer).

Voici un exemple de politique de versioning basée sur les types de commit :

Un commit de type feat peut déclencher une nouvelle version mineure (ex : 1.0.0 -> 1.1.0)
Un commit de type fix peut déclencher une nouvelle version patch (ex : 1.0.0 -> 1.0.1)
Un commit de type refactor ou chore peut ne pas déclencher de changement de version, ou déclencher une nouvelle version patch selon la politique adoptée.

Pour réaliser ce type d’automatisation, il existe de nombreux outils comme semantic-release ou encore Cocogitto que j’apprécie beaucoup qui peuvent analyser les messages de commit et gérer automatiquement la génération de changelogs et le versioning.

Sources

Best Practices on Valérian Pyckaert