Introduction
Conventional Commits est un standard largement utilisé dans les projets open source, mais il est considéré comme un standard actif mauvais qui encourage une focalisation sur les mauvaises choses et échoue à tenir ses promesses.
Contexte Technique
Conventional Commits vise à ajouter une signification sémantique aux messages de commit pour aider les développeurs et les utilisateurs finaux à comprendre les changements apportés dans un commit. Cependant, Conventional Commits échoue à atteindre cet objectif de manière spectaculaire. Un commit Conventional Commits est formaté comme suit : [optional scope] : [optional body] [optional footer(s)].
Ce format a une faille majeure : le type est prioritaire sur la portée. C'est exactement à l'opposé de ce qui devrait être. La portée d'un changement (le sujet du changement) est la partie la plus importante d'un commit.
Analyse et Implications
Les contributeurs, les débogueurs et les intervenants en cas d'incident se soucient tous de la portée d'un changement, et non du type de changement. Conventional Commits dépriorise la portée au point de la rendre optionnelle, ce qui est inacceptable.
De plus, le type de commit est souvent évident à partir de la description, ce qui rend la mention du type dans le sujet du commit superflue et parfois même restrictive.
Perspective
Conventional Commits se concentre sur la mauvaise chose (le type de commit) et dévalue la portée (ce qui compte vraiment pour les développeurs). Les avantages promis par Conventional Commits, tels que la génération automatique de changelogs et la détermination automatique des increments de version sémantique, ne sont pas convaincants.
Il est temps de reconsidérer l'utilisation de Conventional Commits et de se concentrer sur des formats de commit qui donnent la priorité à la portée et à la clarté pour les développeurs et les utilisateurs finaux.
