Conventional Commits : Un Historique Lisible par les Humains

Vous vous souvenez de notre règle "fini l'historique plat de spaghettis" ? Les Conventional Commits (ou "commits conventionnels") sont l'ingrédient le plus important pour y parvenir. C'est un ensemble de règles simples pour vos messages de commit qui rendent votre historique lisible et débloquent des automatisations puissantes.

En formatant nos messages de commit de manière standard, nous pouvons générer automatiquement des changelogs, calculer la prochaine version, et comprendre immédiatement l'impact de chaque changement.

La Règle d'Or

Chaque message de commit doit respecter ce format :

<type>(<scope>): <description>

[corps optionnel]

[pied(s) de page optionnel(s)]

Décortiquons tout ça.

1. Le Type

Il indique la nature du changement que vous avez effectué. Les deux types les plus importants affectent directement le numéro de version du projet :

• feat : Une nouvelle fonctionnalité pour l'utilisateur. (Correspond à une montée de version MINOR en SemVer)
• fix : Une correction de bug pour l'utilisateur. (Correspond à une montée de version PATCH en SemVer)

Nous utilisons aussi d'autres types pour les changements internes qui n'affectent pas le numéro de version. Voici une liste des plus notables :

Type	Description
feat	Une nouvelle fonctionnalité
fix	Une correction de bug
docs	Changements concernant uniquement la documentation
style	Changements de style de code (formatage, points-virgules, etc.)
refactor	Un changement de code qui ne corrige ni bug, ni n'ajoute de fonctionnalité
perf	Un changement de code qui améliore la performance
test	Ajout ou correction de tests
build	Changements qui affectent le système de build ou les dépendances
ci	Changements de nos fichiers et scripts de configuration de CI
chore	Autres changements qui ne modifient pas le code source ou les tests
revert	Annule un commit précédent

2. Le Scope (Ma Règle Spécifique)

Le scope (ou "périmètre") fournit un contexte au changement. Il nous dit quelle partie du code est affectée.

OBLIGATOIRE : TICKET ID

Dans notre workflow, le scope n'est pas optionnel. Au minimum, spécifiez la couche de votre application sur laquelle vous travaillez, mais si vous utilisez un système de tickets (ex: Jira, Azure DevOps, etc.), utilisez-le pour l'ID de la tâche sur laquelle vous travaillez. C'est facilement "parsable" (analysable) et permet de lier chaque changement à une exigence spécifique.

✅ Correct : feat(JIRA-123): ...

❌ Incorrect : feat: ...

3. La Description

Un résumé court et à l'impératif du changement, en 50 caractères maximum.

• À faire : Ajoute le bouton de connexion
• À ne pas faire : Ajout d'un bouton de connexion ou Ajoutera un bouton...

4. Le Corps (Optionnel)

Si votre changement est complexe, vous pouvez fournir une description plus longue dans le corps. Expliquez le "quoi" et le "pourquoi", pas le "comment".

5. Le Pied de page (Optionnel mais puissant)

Le pied de page (footer) est utilisé pour référencer des tickets ou, plus important encore, pour signaler un breaking change (changement cassant).

Pour indiquer un breaking change, commencez une nouvelle ligne dans le pied de page avec BREAKING CHANGE: suivi d'une description de ce qui a été cassé. Cela déclenchera une montée de version MAJOR.

Exemples Concrets

Exemple 1 : Une nouvelle fonctionnalité

feat(JIRA-123): Ajoute le bouton de déconnexion à la page des paramètres

Les utilisateurs peuvent maintenant se déconnecter de leur compte en cliquant sur le nouveau bouton sur la page des paramètres.

Exemple 2 : Une correction de bug

fix(JIRA-456): Empêche la soumission du formulaire avec un email invalide

Le formulaire d'inscription n'accepte plus les adresses email sans le symbole '@', ce qui empêche l'envoi de données erronées à l'API.

Exemple 3 : Un refactor avec un Breaking Change

refactor(AUTH-789): Réorganise le middleware d'authentification

La logique d'authentification a été déplacée de la couche des contrôleurs vers un middleware dédié. Cela simplifie les contrôleurs d'API et centralise le flux d'authentification.

BREAKING CHANGE: Le endpoint `/auth/token` retourne maintenant un objet `{ "accessToken": "..." }` au lieu d'un token brut. Tous les clients doivent être mis à jour pour gérer la nouvelle structure de réponse.

Pourquoi s'embêter avec ça ? Les Bénéfices

Suivre ces règles, ce n'est pas juste pour le plaisir. Ça nous donne des super-pouvoirs :

• 🤖 Changelogs Automatiques : Nous pouvons lancer un script qui transforme ces commits en un magnifique changelog lisible pour chaque release.
• 🚀 Versioning sans Effort : Des outils comme GitVersion peuvent lire l'historique des commits et calculer automatiquement la prochaine version SemVer correcte pour votre projet. Fini les devinettes !
• 🧠 Un Historique Limpide : N'importe qui dans l'équipe (y compris votre "vous" du futur) peut regarder le git log et comprendre ce qui s'est passé, pourquoi, et quelle était l'importance des changements.

Pour la spécification complète, consultez le site officiel de Conventional Commits.