-- Leo's gemini proxy
-- Connecting to unbon.cafe:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini;
Conventional Commits[1] est une spécification visant à standardiser les messages de commits autour du système Git[2] (et potentiellement d'autres systèmes de VCS). Elle définit un format général de sorte à ce qu'il soit possible de créer des outils en surcouche. Le projet s'inspire grandement des règles de contribution à Angular.
Un soin particulier a été apporté pour correspondre à la gestion sémantique de version[3]
Le modèle à suivre est défini selon :
<type>[(Contexte facultatif)]: <description> [Corps facultatif] [Pieds de page facultatifs]
Le type est l'élément au cœur de la spécification, et peut prendre différentes valeurs, comme `fix` (équivalent à un Patch en SemVer) ou `feat` (équivalent à un Minor), build, chore, ci, docs,… et d'autres encore.
À noter qu'un changement important (Major), peut être indiqué via en pied de page `BREAKING CHANGE: <description>`, ou `!` après le contexte en en-tête.
D'autres types de pied de page peuvent également être utilisés.
Mon avis, en tant que novice sur Git ? C'est pourri.
L'idée initiale est intéressante. Les standards c'est des étiquettes barbantes à suivre, mais ça permet une harmonie des pratiques et leur évolution. Le problème principal c'est qu'ici j'arrive pas à voir en quoi c'est utile, et les quelques arguments avancés sont très légers.
> Automatically generating CHANGELOGs.
Moui, mais ça sous entend une description intéressante, sinon on se retrouve avec des <type> sans intérêt.
> Automatically determining a semantic version bump (based on the types of commits landed).
Moui, je pense que les personnes en charge du commit et du merge en ont conscience pour le faire manuellement.
> Communicating the nature of changes to teammates, the public, and other stakeholders.
Si les messages de commit étaient pas clairs c'est la responsabilité de la personne derrière qui est en jeu, pas le système.
> Triggering build and publish processes.
On attendrait avant de publier des correctifs ?
> Making it easier for people to contribute to your projects, by allowing them to explore a more structured commit history.
J'ai du mal à saisir le lien entre l'exploration des commits et la contribution. Quand je cherche à aider je démarre par un fichier d'intérêt.
En plus de quoi, le manque de rigueur de la spécification me déplait particulièrement. Sans revenir sur le sac de nœuds qu'est la spécification Markdown, parfois également reproché au CSV (pourtant clair, « CommaSeparatedValues »), c'est la rigueur qui permet d'uniformiser les pratiques et atteindre l'harmonie visée par un standard. Ici, sont consciemment laissés ouverts les types possibles, idem pour les pieds de page. Pire encore, leur définition repose sur un lien vers d'autres projets[4] !
Ce manque de rigueur se retrouve également dans la déclaration de changements importants, ceux-ci requiert l'usage de `BREAKING CHANGE:` en pied de page… ou de `BREAKING-CHANGE`… ou en en-tête, en quel cas il faut utiliser `!`… ou en pied et en-tête en quel cas sa description sera celle de première ligne… d'ailleurs les informations ne sont pas sensibles à la casse, sauf pour les `BREAKING(-)CHANGE:|!`.
Une série d'outils est mise en avant dans la section « À propos », ne méritant à priori pas leur propre place dans la barre de navigation…
Tout ça pour dire que je suis désormais au courant de cette initiative, et que je vais consciemment l'ignorer faute de règles strictes, et accessoirement d'utilité.
-- Response ended
-- Page fetched on Sun May 19 02:25:32 2024