Rédiger le changelog d’un projet WordPress à la main, au moment de chaque livraison, produit presque toujours le même résultat décevant : une liste imprécise reconstituée de mémoire, souvent incomplète, parfois carrément oubliée quand la livraison se fait dans la précipitation. Les commits conventionnels (conventional commits) proposent une autre voie : normaliser dès l’écriture du message de commit son type de changement, pour ensuite générer automatiquement un changelog structuré, classé par catégorie, sans aucune rédaction manuelle supplémentaire.
Cette approche se distingue du versionnage automatisé des extensions avec release-please : ici, il s’agit uniquement de produire un historique de changements lisible pour chaque livraison, pas de gérer automatiquement le numéro de version ni la publication elle-même.
Le format d’un commit conventionnel
Chaque message de commit suit une structure fixe : un type, un champ optionnel de portée entre parenthèses, puis une description courte :
feat(panier): ajoute un calcul de frais de port par zone
fix(formulaire-contact): corrige la validation de l'adresse e-mail
chore(dependances): met à jour Composer vers 2.6
docs(readme): précise la procédure d'installation localeLes types les plus courants sur un projet WordPress d’agence se limitent en pratique à trois grandes catégories : feat pour une nouvelle fonctionnalité, fix pour une correction, et chore pour tout ce qui ne modifie pas le comportement observable (mise à jour de dépendances, tâches de maintenance). D’autres types existent (docs, style, refactor, test), à adopter selon la granularité souhaitée par l’équipe.
Faire respecter le format avant qu’il n’arrive dans l’historique
Un hook Git local, via l’outil commitlint, rejette un commit qui ne respecte pas le format attendu, avant même qu’il n’entre dans l’historique du dépôt :
npm install --save-dev @commitlint/cli @commitlint/config-conventional
echo "module.exports = { extends: ['@commitlint/config-conventional'] }" > commitlint.config.jsAssocié à Husky pour déclencher la vérification au moment du commit, ce contrôle évite qu’un message mal formé (« corrige un truc », « wip ») ne vienne polluer l’historique et rendre la génération du changelog incomplète ou incohérente.
Générer le changelog
L’outil conventional-changelog-cli parcourt l’historique Git et produit un fichier structuré, classé par type de changement, directement à partir des messages de commit déjà présents dans le dépôt :
npx conventional-changelog -p angular -i CHANGELOG.md -sLe résultat, généré automatiquement, ressemble à ceci :
## [2.4.0] - 2023-08-18
### Nouvelles fonctionnalités
* **panier:** ajoute un calcul de frais de port par zone
### Corrections
* **formulaire-contact:** corrige la validation de l'adresse e-mail
### Maintenance
* **dependances:** met à jour Composer vers 2.6Intégrer la génération dans un pipeline
Plutôt que de lancer cette commande manuellement à chaque livraison, un job GitHub Actions peut générer et committer automatiquement le changelog mis à jour à chaque fusion sur la branche principale, garantissant qu’il ne soit jamais oublié ni désynchronisé de l’historique réel des changements.
Ce que cette approche demande en discipline d’équipe
- Chaque membre de l’équipe doit adopter le format dès le premier commit du projet : reprendre un historique existant non conventionnel pour le reclasser rétroactivement est fastidieux et rarement fait avec précision.
- Un commit qui mélange plusieurs types de changements (une correction et une nouvelle fonctionnalité dans le même commit) complique la classification automatique : mieux vaut scinder les commits en amont.
- Le champ de portée (le mot entre parenthèses) doit rester cohérent d’un commit à l’autre pour que le changelog reste lisible, ce qui suppose une convention de nommage partagée par l’équipe.
Un changelog généré automatiquement n’est fiable que si la discipline d’écriture des commits est tenue en amont. Le meilleur outil de génération ne rattrape jamais un historique de commits mal renseigné.
En résumé
Adopter les commits conventionnels sur un projet WordPress transforme la rédaction du changelog d’une corvée manuelle, souvent négligée, en un sous-produit automatique de l’historique Git déjà existant. Le coût d’entrée se limite à une discipline d’écriture des messages de commit, largement compensée par le temps économisé et la fiabilité gagnée à chaque livraison.
