- Conventional Commits tente de donner du sens aux messages de commit avec le format
<type>[optional scope]: <description>, mais met en avant le type de changement et relègue le périmètre en option, repoussant ainsi l’information réellement utile pour l’exploration
- Les contributeurs, débogueurs et équipes de réponse aux incidents cherchent dans le log des commits les zones de code touchées par un changement, et comme un bug peut apparaître dans n’importe quel type de modification, le scope est plus important que le type
- Avec
fix(compiler): prevent namespaced SVG <style> elements from being stripped, la description suffit déjà à indiquer qu’il s’agit d’un correctif de bug, et avec refactor(core): Update webmcp support to use document.modelContext, un même commit peut relever à la fois de la correction, du refactoring et de l’ajout de fonctionnalité, ce qui rend le type redondant et limité
- La génération automatique du CHANGELOG et la décision d’augmenter une version sémantique posent problème, car les lecteurs du log des commits et du journal des changements ne sont pas les mêmes, et le résultat peut diverger à cause des revert, des ruptures de compatibilité accidentelles ou de corrections ultérieures de ces ruptures
- Les messages de commit à préfixe de scope montrent d’abord l’objet du changement, et pour les conditions de build ou de déploiement, il vaut mieux se baser sur les fichiers modifiés via
git diff que sur le type indiqué dans le titre
Des priorités erronées
- Conventional Commits a pour objectif de donner du sens aux messages de commit afin d’aider les développeurs et les utilisateurs finaux à comprendre les changements
<type>[optional scope]: <description>
[optional body]
[optional footer(s)]
- La ligne de titre se compose d’un
<type> comme fix, feat, chore, docs ou refactor, d’un scope optionnel et d’une description
- Son défaut fondamental est de donner la priorité au type de changement plutôt qu’au scope, c’est-à-dire à la cible réelle du changement
- Le fait que le scope soit optionnel permet de faire disparaître l’information la plus importante d’un commit, et placer le type tout au début du titre inverse les priorités
Pourquoi le scope est plus important que le type
- Les contributeurs lisent le log des commits pour repérer les changements depuis leur dernière contribution, le flux global du projet et les commits susceptibles d’entrer en conflit avec leur travail en cours lors d’un pull ou d’un rebase
- Les débogueurs cherchent les changements qui ont touché les zones liées au composant où le bug s’est manifesté, et comme un bug peut apparaître dans n’importe quel type de modification, l’information de type n’aide pas
- Les équipes de réponse aux incidents parcourent le log autour du moment de la panne pour trouver la zone en cause ; si une hausse des erreurs sur l’API entrante coïncide avec un commit de scope
auth, cela devient un candidat crédible
- Pour les personnes qui lisent le log des commits, l’information importante n’est pas la nature du changement, mais la zone qu’il a touchée
La redondance et les limites du type
fix(compiler): prevent namespaced SVG <style> elements from being stripped indique déjà, par la seule description, qu’il s’agit d’une correction de bug, ce qui rend le type fix redondant- L’espace disponible dans la ligne de titre d’un commit étant limité, consacrer des caractères à un type déjà déductible de la description n’aide pas
refactor(core): Update webmcp support to use document.modelContext met à jour la fonctionnalité webmcp du composant core afin de prendre en charge à la fois document.modelContext et navigator.modelContext- Ce changement peut être vu simultanément comme une correction, un refactoring et une nouvelle fonctionnalité, alors que l’information vraiment importante est qu’il concerne le composant
core/webmcp
Les limites de la promesse d’automatisation
- L’idée de générer automatiquement un CHANGELOG à partir des commits avec des outils comme git-cliff ou conventional-changelog se heurte au fait que les lecteurs du log des commits et du journal des changements ne sont pas les mêmes
- Un CHANGELOG s’adresse aux utilisateurs et se concentre sur la compréhension des différences fonctionnelles et métier entre deux versions
- Le log des commits s’adresse aux développeurs et se concentre sur la façon dont la base de code évolue dans le temps ainsi que sur son flux du point de vue des scopes
- Dans un projet d’une complexité au moins intermédiaire, une fonctionnalité significative arrive souvent en plusieurs commits ; pour les développeurs, le processus d’implémentation est utile, mais pour l’utilisateur final, seule la nouvelle fonctionnalité compte
- Les commits de revert sont importants pour les développeurs dans le déroulé du log, mais pour l’utilisateur final, une modification annulée équivaut à une modification qui n’a jamais existé
- L’augmentation de version sémantique fondée sur le type du commit peut conduire à augmenter une version majeure alors qu’un changement cassant a été revert, à incrémenter à tort en minor/patch parce que la rupture n’a été détectée que plus tard, ou à juger un changement cassant alors qu’une série de commits ultérieurs a supprimé cette rupture
- On peut corriger l’historique avec un rebase dans de telles situations, mais le workflow peut l’empêcher ou le fragiliser, et cela réduit la fiabilité du récit porté par le log des commits
- Déclencher les processus de build ou de déploiement à partir du type dans le titre d’un commit permet aussi de contourner les outils automatiques, par exemple avec un commit intitulé
docs: fix typos qui introduit en réalité une faille dans le sous-système d’authentification
- Pour les conditions de build et de déploiement, il vaut mieux identifier les fichiers modifiés via
git diff que se fier au titre du commit
Problèmes d’adoption et alternative
- Conventional Commits demande de définir un ensemble de types propre à chaque projet, mais beaucoup de projets reprennent simplement les types par défaut de commitlint, qui peuvent mal correspondre aux spécificités du projet
- La spécification Conventional Commits ne définit en pratique que
fix et feat, et laisse les autres types à la discrétion du projet
- En environnement d’entreprise, des exigences de gestion du changement et d’audit imposent parfois d’inclure un numéro de ticket dans tous les messages de commit ; si
<scope> sert à y mettre ce numéro, on perd une métadonnée utile
- Linux, FreeBSD, Git, Go, NixOS et Node.js utilisent des messages de commit à préfixe de scope adaptés à leur projet
- Dans le noyau Linux, le sous-système constitue un scope naturel ; dans le projet Go, c’est le chemin du package ; dans une architecture en microservices, ce sera le nom du microservice
- scopedcommits.com défend un retour à un format de message de commit centré sur le scope et une séparation entre génération du CHANGELOG et gestion du log des commits
- Les avantages supposés de Conventional Commits ne se sont pas traduits en bénéfices réels, et sa popularité dans l’open source ainsi que la tendance des IA à le choisir par défaut ont favorisé la diffusion de messages de commit mêlant des antipatterns
2 commentaires
Réactions sur Hacker News
Les programmeurs finissent toujours par débattre et se plaindre de la configuration optimale, même pour des détails mineurs comme les tabulations et les espaces
Cela ne veut pas dire que Conventional Commits est la meilleure solution possible, comme une sorte de révélation divine pour structurer les messages de commit, mais je pense qu’avoir une structure définie et aligner les attentes sur les messages de commit est bien plus efficace et important
L’auteur insiste beaucoup sur le fait que le scope est plus important que le type, mais à mon avis, la différence entre
fix(compiler)etcompiler fixn’est pas non plus une affaire de vie ou de mortL’industrie tech compte beaucoup de choses devenues des standards sans être optimales ; par exemple, beaucoup estimeraient que si l’on recréait JSON depuis zéro, il faudrait prendre en charge les commentaires, des formats numériques plus clairs, etc.
Malgré cela, il est devenu un standard parce qu’il était meilleur que ce qui existait avant dans de nombreux contextes, et même s’il peut exister un format un peu meilleur que Conventional Commits, il ne semble pas suffisamment meilleur pour justifier encore une autre approche concurrente de la structure des messages de commit
Un message de commit peut être excellent avec une structure souple s’il transmet bien la nature du changement, et à l’inverse il peut être très structuré tout en restant confus ou vide d’information
Globalement, je suis d’accord avec l’auteur : Conventional Commits ne résout pas le problème de fond, à savoir les mauvais messages de commit
XML est suffisamment bon et c’est un standard, SOAP est suffisamment bon et c’est un standard
Dire que Conventional Commits est suffisamment bon et suffisamment standardisé pour qu’il ne vaille pas la peine d’examiner d’autres structures, c’est faire reposer cette “valeur” sur quelque chose de subjectif
Si l’on commit tous les jours et qu’on lit des PR quotidiennement, même les petites frictions créées par le format Conventional Commits peuvent s’accumuler ; ne pas le considérer comme une loi naturelle et laisser d’autres options peut aider les équipes qui les préfèrent
De toute façon, la plupart des équipes ne génèrent même pas de changelog
Que le scope soit important, oui, mais on devrait pouvoir le déduire du contenu du commit
Quand on relit un diff, regarder les chemins touchés est un important sanity check, et un diff “test” ne devrait pas modifier du code d’authentification de production
Cela dit, si l’on veut l’afficher dans
--oneline, je trouve quefeat(auth):est préférable àfeat:Je ne suis pas d’accord avec l’idée que le public visé se trompe
Un commit
featdevrait effectivement décrire un changement du point de vue du produit, et il faudrait d’abord empiler correctement les changements de refactoring sans signification particulière, puis ajouter par-dessus un petit changement de nouvelle fonctionnalitéC’est aussi ce qu’il y a de plus utile à mettre dans la description du diff, et le contexte technique du type “pourquoi avons-nous choisi l’algorithme X” devrait être consigné dans des commentaires ou dans
DECISIONS.mdpour éviter de le perdreDans une entreprise qui va vite, il n’y aura sans doute que les plus obsessionnels pour s’occuper de ce genre de corvée dans l’historique Git, mais dans un projet open source, je pense qu’il est bien plus important de laisser ce contexte dans les messages de commit
S’il existe des formats comme Markdown et le texte brut, et pas uniquement JSON, ce n’est pas sans raison
J’ai relu bien trop de commits dont le titre était
small fixalors qu’en réalité il ne s’agissait pas du tout d’une petite correctionLa vraie conclusion, c’est que les exigences diffèrent selon les projets
Après plus de 30 ans à utiliser la gestion de code source, je n’ai jamais eu une seule fois un cas où il était utile d’insérer le composant dans la description d’une manière standardisée (appelé
scopedans l’article)Il suffit de voir où se trouvent les fichiers affectés dans l’arborescence du code source pour savoir clairement quel composant a changé, et
bug,fixetfeaturen’apportent pas non plus de valeur utileSi ce n’était pas important, cela n’aurait pas été commit
La seule chose que j’ai trouvée utile, et que l’article n’aborde pas du tout, ce sont les liens ou ID de demandes de modification associées
Un commit contient déjà des informations sur ce qui a changé ; ce qui manque, c’est le contexte de pourquoi cela a changé
Même dans mes projets personnels, je mets une référence JIRA entre crochets au début de la description, et même si c’est quelque chose que j’ai décidé de corriger au passage pendant le développement, je crée un JIRA d’une ligne très courte pour obtenir un ID et j’y note la raison
Capturer le « pourquoi », c’est tout l’objectif de ce message, et y ajouter à la place un simple lien vers une ressource externe qui pourra disparaître un jour n’est pas un bon substitut
Avec des issues GitHub, on peut remonter du commit à la discussion de la PR, et cette PR doit avoir des liens vers l’issue associée et d’autres pointeurs
Bien sûr, en passant aux issues GitHub, nous avons presque abandonné JIRA, puis quelques années plus tard l’instance a été arrêtée et supprimée
Maintenant, tous ces tags JIRA sont devenus inutiles
Du coup, je pense qu’il faut au contraire un couplage fort entre l’outil de suivi d’issues et le dépôt git
Ce qu’on veut vraiment, c’est la portabilité, mais je ne vois pas comment l’obtenir sans ce couplage fort
Dans l’idéal, il devrait y avoir un format standard ouvert, mais en pratique GitHub est le gorille de 800 kilos qui définit le format, et si GitLab et les autres clones peuvent importer les métadonnées de projets GitHub, ou au moins les PR, on s’en approche déjà concrètement
Quoi qu’il en soit, une politique consistant à laisser des pointeurs fixes et immuables vers un produit Atlassian qu’on n’utilisera peut-être plus dans 5 ans n’est pas bonne
Je préférerais encore adopter une politique où les commits git doivent se suffire totalement à eux-mêmes et où toutes les informations sur le « pourquoi » du changement doivent être intégrées dans le message de commit ou dans les commentaires du code source
Cela dit, je pense aussi que ça échoue, parce que les gens écrivent trop brièvement dans les commits git et perdent de l’information en résumant les issues, tandis que les allers-retours de la discussion de PR contiennent souvent plus qu’un simple résumé à une seule voix de la raison du changement, ce qui les rend utiles
Regrouper d’abord les nouvelles fonctionnalités puis les corrections de bugs rend la lecture un peu plus facile pour les utilisateurs non techniques
Les messages de commit ne sont pas faits pour générer un changelog, mais pour les développeurs du futur
Le moment principal où ce développeur lit le message de commit, c’est lorsqu’il ne comprend pas pourquoi ce commit existe
Il ne se demande pas ce qui a changé, mais à quoi sert une ligne donnée
Il lance donc
blame, consulte le commit, le développeur d’origine a déjà quitté l’entreprise, l’ancien JIRA a peut-être disparu, et le seul indice restant est le message de commithttps://dev.to/splix/the-why-behind-the-code-2bb1
On ne peut pas simplement mettre le contexte dans le corps du commit ?
Chez beaucoup de gens qui utilisent Conventional Commits, le mot
chorem’a toujours agacéPersonnellement, j’ai toujours préféré les titres de commit dans le style du noyau Linux, qui heureusement sont aussi mentionnés ici
[0] https://www.kernel.org/doc/html/v7.0/process/submitting-patc...
L’attitude implicite suggérée par
choreme rebute profondémentOn a presque l’impression qu’il faudrait marquer tout le reste comme
funouindifferent, et ce genre de jugement émotionnel n’a rien à faire dans un message de commitupkeepCela veut dire la même chose, mais sans la nuance méprisante
En plus, cela revient à faire semblant de connaître à l’avance l’impact global du commit, alors qu’en réalité on ne le sait pas
Dès que Conventional Commits est en place, les membres de l’équipe comme les LLM doivent tous dépenser du temps et des tokens à produire cette nomenclature idiote
Mon principal reproche à Conventional Commits, c’était que les titres de commit n’incluent pas de numéro d’issue
Ce n’est même pas mentionné comme option dans le document standard
Pour moi, c’est presque l’information la plus importante dans un message de commit
Je ne sais pas combien de fois, au cours des 15 dernières années, j’ai comparé la description d’une issue référencée par un ancien commit pour reconstituer tout le contexte d’un changement
J’avais l’impression que cette habitude était une sorte de standard, mais ce n’est qu’en découvrant Conventional Commits que j’ai appris que ce n’était pas le cas
Je n’ai jamais compris pourquoi c’était populaire
Personnellement, je préfère mettre l’issue en git trailer
fix thing in fooIssue: ABC-123Git dispose de nombreuses fonctionnalités intégrées pour analyser et formater ce type de trailer, donc il est facile de créer un alias
git logpersonnalisé pour les consulter en ligne ou les parser dans la CI.Si je parcours déjà un changelog dont le nombre de caractères est limité, voir
XYZ-999999dans le message de commit principal ne m’intéresse pas vraiment.Ajouter un tag via un trailer, très bien, mais je préfère de loin voir ce que le commit a fait plutôt que le numéro du ticket Jira.
Je ne vois ça comme un problème que lorsqu’on exige de mettre la clé d’issue tout au début du titre.
Et je pense que c’est mauvais pour la lisibilité.
Je ne vois pas pourquoi on ne pourrait pas simplement l’ajouter quelque part après tout le fatras de formatage de Conventional Commits.
Comme une clé d’issue doit pouvoir être extraite avec une regex du type chiffres après un préfixe alphanumérique, ce genre de « standard » n’a quasiment pas besoin de lui réserver un espace distinct.
Personnellement, sans Conventional Commits, si le commit est lié à l’issue en question, je le mets simplement entre parenthèses à la fin.
Si le lien est plus fort, par exemple quand le commit corrige l’issue, j’ajoute aussi un trailer
Fixesdans le message.Intéressant.
Jusqu’ici, nous avons écrit des messages comme
fix(ABC-123): some message here, et les liens se font bien, en plus du rendu très propre dans les notes de version automatiques.Ce n’est pas un standard mais une convention.
Il suffit de définir au sein de l’équipe une règle pour inclure l’ID du ticket dans les messages de commit.
Si vous voulez quelque chose de lisible par une machine, utilisez des footer/trailer.
Je n’ai rien de positif à dire sur Conventional Commits.
Le format occupe de la place dans la partie la plus lue du message, et les catégories ou types apportent peu d’information.
On peut le remplacer par un verbe anglais explicite dans le titre, rédigé comme une phrase, et une phrase se lit bien mieux que trois signes de ponctuation comme
:,()et!.Je tolère à la rigueur la notion de « portée » dans le titre, et de toute façon elle existait avant cette convention.
Au travail, nous développons une web app pour des utilisateurs non techniques, et le changelog destiné à ces utilisateurs peut très bien être rédigé en norvégien.
Les messages de commit ne concernent pas les utilisateurs, et exiger que chaque commit soit assez bon pour figurer dans un changelog destiné aux utilisateurs finaux n’est pas près d’arriver chez nous.
À la place, il suffit d’utiliser des footer/trailer.
Là où Conventional Commits aide vraiment, c’est pour le déploiement continu.
On peut ajouter automatiquement des tags SemVer et déployer à chaque merge vers
main, parce que les décisions nécessaires pour le tagging et la gestion de version ont déjà été prises par le développeur au moment d’écrire le message de commit.J’admets volontiers que ce n’est pas adapté à des projets énormes comme le noyau Linux.
Mais pour 99 % des projets, combiner Conventional Commits et SemVer améliore nettement le processus de release actuel et le rend plus facile à automatiser.
git tags.git describesuffit souvent pour la gestion de version en déploiement continu, etv1.2.3-4-gabcdefdécrit souvent un commit avec une précision suffisante pour Git tout en ressemblant assez à SemVer pour poser les bonnes attentes.C’est particulièrement vrai lorsque de nouveaux
git tagsne sont ajoutés qu’après une décision humaine, par exemple quand on juge qu’il s’agit d’un changement cassant et qu’il faut donc taguer une nouvelle version majeure.Avec des numéros de version au format
git describe, le seul vrai débat consiste souvent à savoir s’il faut remplacer le premier tiret par un plus pour mieux coller aux attentes de SemVer, et si cela apporte une vraie valeur du côté où l’on veut imposer ces attentes de SemVer, par exemple pour trier correctement les versions dans un gestionnaire de paquets, on peut le convertir avec une simple regex.git describeest facile à automatiser pour la CD, mais permet de laisser la décision du numéro de version à un humain via le choix d’ungit tagou des GitHub Releases, plutôt que de la déduire à partir de mots-clés magiques dans l’historique des commits.Au travail, nous imposons aussi des « tags » selon le public concerné par le changement.
Ici, tag ne veut pas dire tag Git, mais une chaîne dans le titre de la PR, et nous générons des changelogs pour chaque équipe à partir de ces « tags ».
Si vous voulez versionner de cette manière étrange, vous pouvez mettre une formule magique dans le corps du commit.
Et comme ça, on n’est pas limité à un seul mot.
Je déteste assez ce style de titre.
Des formulations comme « Stop something » ont l’air très populaires, mais c’est à l’impératif et ça donne une impression de « j’ai forcément raison ».
Je ne comprends pas pourquoi on n’écrit pas plutôt des choses comme « In favour of something » ou « A case against something ».
Pas besoin d’être d’accord avec cette position, mais exiger qu’on l’édulcore me paraît être une réponse faible.
considered harmful, mais c’est quand même légèrement toxique.Le fond du problème semble être la volonté de faire paraître plus important qu’il ne l’est un simple goût personnel arbitraire, par exemple l’envie d’inverser l’ordre entre A et B.
Pour beaucoup, c’est impoli, mais l’économie de l’attention récompense ce genre d’approche.
Édition : le titre a l’air d’avoir été rendu moins provocateur.
Bonne décision.
Je n’aime pas beaucoup Conventional Commits, mais il suffit de laisser chacun utiliser ce qu’il veut.
Il existe un mème qui a influencé une partie des titres de ce genre.
C’est étrange
La principale raison d’utiliser ce style de message de commit, c’est l’automatisation CI/CD
Édit : je n’avais pas vu cette partie dans l’article à la première lecture, mais elle était bien abordée
Désolé
Le type de commit est placé au tout début parce qu’il indique au workflow automatisé comment traiter le commit
Par exemple, si on fait du CD, une série de commits
fix:n’incrémente que le numéro de patch du versionnage sémantiqueUn commit
feat:fait monter la version mineure, etfeat!entraîne une augmentation de la version majeureMême sans utiliser le CD pour les releases, les messages de commit sémantiques servent aussi parfois à automatiser la génération du changelog
Bien sûr, on ne devrait généralement pas mettre les messages de commit Git eux-mêmes dans un changelog
Ces messages s’adressent aux développeurs, pas aux utilisateurs
Le versionnage sémantique casse lors des rollbacks, et les changelogs automatiques visent le mauvais public
Ces temps-ci j’utilise CalVer au lieu de SemVer, donc ce n’est plus vraiment un problème, mais l’idée d’un incrément de version intelligent me plaît bien
Même s’il y a
fixoufeatdans le titre du commit, ça n’apporte aucune information utile à la personne qui parcourt le logLe propos, c’est qu’il faut se débarrasser de Conventional Commits pour que l’IA puisse faire des commits plus facilement
Si on inverse l’ordre, ça résout effectivement mon irritation principale
Au juste, qu’est-ce qu’une fonctionnalité ?
refactor(core): Update webmcp support to use document.modelContextComme le dit l’auteur, les frontières entre correction, amélioration et rangement général sont floues, et séparer chaque changement sémantique en commit distinct crée de toute façon du travail qui ne profite à personne, puisque tout pourra finir squashé plus tard
À mes yeux, Conventional Commits est un sous-produit d’une tentative d’automatisation de SemVer, plus qu’une solution directe à un autre problème
Je pense de toute façon qu’un changelog ne devrait pas être automatisé
Si on a besoin d’une liste, il suffit de regarder
git logUn changelog est une occasion de faire comprendre à un public plus large ce qui se passe réellement en interne
« Le lectorat d’un changelog est complètement différent de celui d’un journal de commits »
« Un changelog est destiné aux utilisateurs »
J’ai l’impression que c’est déjà trop tard
La plupart des entreprises se contentent de « Bug Fixes & Performance Improvements »
Au minimum, si l’on ne va pas faire l’effort, un changelog généré vaut mieux que pas de changelog du tout
uv:Ensuite, chaque semaine, je les recherchais et j’utilisais le texte tel quel ou je le retouchais légèrement
Je les mettais aussi dans le menu Help/Release-notes du produit lui-même
C’est un peu drôle de dire à quelqu’un d’arrêter de faire quelque chose que je fais déjà sans même en avoir entendu parler
En général, on ne met des préfixes spéciaux que pour les migrations de schéma de base de données ou d’autres éléments importants
Il semble aussi mal nommer ses commits, et probablement aussi ses noms de symboles
C’est un problème de compétence, et comme il s’en plaint publiquement, on peut juste passer à autre chose
Avis sur Lobste.rs
Je suis content de voir un texte qui formule une critique des conventional commits avec des arguments plutôt qu’un simple rejet instinctif.
Je n’avais pas vraiment réfléchi en profondeur à pourquoi je n’aimais pas ça, et je me demandais si ce n’était pas lié au fait que je l’associe au code généré par les LLM. Je déteste surtout
chore:et j’aimerais qu’on évite de réinventer la notation hongroise. Ça n’aurait jamais dû être créé au départ.chore:n’existe même plus dans le guide de style de commit Angular et a été absorbé parbuild:, sans doute parce qu’ils se sont rendu compte que c’était trop vague.Même à l’époque où il figurait dans le style Angular, la description de
chore:indiquait des usages assez précis, mais dans certains projets open source, on a l’impression qu’il est collé par ambiance à des tâches qui ressemblent littéralement à des corvéesJe n’aime pas spécialement les conventional commits, mais l’alternative proposée semble passer à côté de la raison pour laquelle le scope est optionnel.
Dans les petits projets sans modules bien distincts, la notion de « scope » n’est pas très utile. Une pratique utile que les deux camps omettent, c’est d’ajouter un numéro d’issue ou de ticket dans le titre du commit : ça donne plus facilement du contexte sur le changement et c’est particulièrement utile pendant la revue de code. En revanche, je n’aime pas l’idée de rendre le numéro de ticket obligatoire, parce que ça finit par produire des tickets inutiles pour des changements mineurs. Mais si une modif traite un bug ou une tâche précise, elle devrait être liée à ce bug ou à cette tâche.
C’est toujours mieux qu’un « type » de commit redondant qui devrait déjà ressortir rien qu’à la lecture de la ligne de titre
Si un changement correspond clairement à un ticket, on peut faire un commit avec « numéro de ticket » ; sinon, on peut employer une autre forme. Certains changements collent bien à un type mais moins à un scope, et inversement, donc on peut aussi mélanger scoped commits et conventional commits
J’ai envie de dire : « n’utilisez pas une police à chasse fixe dans du texte en paragraphe ».
Cela dit, je suis globalement d’accord avec la prémisse de l’article
Même si les messages de commit ne sont pas terribles, pour se faire une idée de l’ampleur d’un changement, je recommande d’utiliser souvent
git log --name-onlyougit log --stat.Voir les noms de fichiers aide beaucoup à comprendre ce qui a changé sans avoir à ouvrir chaque commit un par un
Une approche que j’aime vraiment, c’est d’imposer le style conventional commit sur les titres de PR.
Les titres de PR peuvent être modifiés par les maintainers même après la fusion, ça évite de réécrire l’historique des commits, et avec des outils comme release-drafter, on peut automatiser un changelog pertinent dans les releases GitHub. Ça offre une granularité adaptée aux parties prenantes évoquées par l’auteur, en séparant fonctionnalités, corrections et ruptures de compatibilité, tout en gérant automatiquement un semver raisonnable pour le prochain brouillon de release GitHub.
L’auteur a raison de dire qu’un composant comme
parse-libne devrait pas être optionnel, et je suis aussi d’accord sur le fait qu’imposer les conventional commits peut décourager les nouvelles contributions. Mais les alternatives ne sont pas forcément meilleures.Cela dit, un identifiant de rupture de compatibilité comme
fix!(parse-lib): Don't leave sparse holes when parsing JSON arraystransmet quand même pas mal d’informations. On comprend qu’il s’agit d’un correctif sur un composant précis, qu’il s’accompagne inévitablement d’une rupture de compatibilité, et qu’il porte un sens du type incrémentation semver mineure. Ce genre de chose peut très bien être utilisé dans un titre de PRJe reconnais avoir trop misé sur les conventional commits comme moyen d’encourager une discipline des commits, au point d’en faire une habitude.
Aujourd’hui, ça me semble souvent limité et arbitraire. Sur certains projets, sans même savoir si c’était la vraie convention, je me suis rapproché d’un style Linux/Go/Node, et dans des monorepos avec beaucoup de configuration, il paraissait plus naturel d’écrire
[service]: [what changed]que d’inventer de force un type. À l’avenir, j’ai envie d’expérimenter davantage mon style personnel de commit en me demandant surtout ce qui semble utile, plutôt que de me conformer à des règles strictes, et les scoped commits me paraissent être un bon point de départchore(lobsters): add my 2 cents on conventionals commits [JIRA-69420]Je suis d’accord avec presque tout, mais je diverge sur un point : l’idée que cela « montre aux contributeurs un historique révisionniste qui réduit la fiabilité de l’histoire racontée par le journal des commits ». L’auteur semble parler principalement des branches publiques, et dans ce cas c’est un conseil raisonnable. Mais cela ne devrait pas s’appliquer aux branches privées. Il faut surtout que la personne qui relit le changement final — le maintainer ou moi dans dix ans — puisse le comprendre facilement ; il n’est pas nécessaire de conserver un cheminement de pensée incohérent, ni pire encore, une série de commits
address reviewLa réponse à « pourquoi le scope est-il optionnel ? » est que, dans les petits projets, le projet entier est simplement le scope.
Je suis d’accord pour dire que le « type » du commit n’est pas très utile, mais je ne vois pas non plus une énorme différence entre scoped commits et conventional commits. Les scoped commits, c’est juste du conventional sans le « type », et distinguer fix, feat, refactor et chore n’est pas forcément absurde.
Si tout le monde se contente de reprendre les valeurs par défaut de commitlint, est-ce qu’il ne suffirait pas plutôt de faire en sorte que les gens les maîtrisent mieux ?