La spécification de Conventional Commits est une convention légère pour des messages de commit propre. Il fournit un ensemble simple de règles pour créer un historique de commit explicite; Ce qui facilite l’écriture d’outils automatisés. Cette convention est liée à SemVer, en décrivant les fonctionnalités, les correctifs et les modifications importantes apportées aux messages de commit.

Le commit contient les éléments structurels suivants, permettant de communiquer à l’intention des consommateurs de votre bibliothèque:

• fix: un commit de type fix corrige un bogue dans le code (cela est en corrélation avec PATCH en versioning sémantique).
• feat: un commit de type feat introduit une nouvelle fonctionnalité dans le code (cela est en corrélation avec MINOR en versioning sémantique).
• BREAKING CHANGE: un commit qui a dans le pied de page le mot clef BREAKING CHANGE:, ou ajoute un ! après le type/scope, introduit un changement cassant l’API (cela est en corrélation avec MAJOR en versioning sémantique). Un BREAKING CHANGE peut faire partie des commits de n’importe quel type.
• Les types autre que fix: et feat: sont autorisés, par exemple @commitlint/config-conventional (basé sur the Angular convention) recommande build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, etc.
• Les pieds de pages autre que BREAKING CHANGE: <description> peuvent être fourni et suivre une convention similaire à git trailer format.

Les types supplémentaires ne sont pas prescrits par la spécification de Conventional Commits et n’ont aucun effet implicite dans la gestion des versions sémantiques (à moins qu’ils ne comportent un BREAKING CHANGE). Un scope peut être fournie au type d’un commit pour fournir des informations contextuelles supplémentaires. Il est contenu entre parenthèses, par exemple, feat(parser): add ability to parse arrays.

Exemple :

• feat(preprod/network): Allow client's office network on the bastion (ISS-123456)

https://www.conventionalcommits.org/en/v1.0.0/