Aller au contenu
Tout en local

Générateur de commits conventionnels

Composez un message de Conventional Commits à partir d'un type, d'une portée et d'une description, ou vérifiez les messages existants pour les problèmes.

Entrée
Sortie

Générateur de commits conventionnels

Conventional Commits est le format "type(scope): description" que les générateurs de changelog, semantic-release et commitlint attendent tous. Cet outil en compose un pour vous : choisissez un type, ajoutez une portée optionnelle, écrivez la description, et il assemble l'en-tête — plus un corps et un pied de page avec les références de tickets, si vous les ajoutez. Basculez en mode vérification pour faire le contraire : collez un ou plusieurs messages de commit existants, un par ligne, et voyez exactement ce qui ne va pas avec chacun.

La liste des types couvre l'ensemble standard — feat, fix, docs, style, refactor, perf, test, build, ci, chore et revert. Un basculement de changement important marque l'en-tête avec "!" et, une fois que vous ajoutez une note, ajoute une ligne de pied de page "BREAKING CHANGE:", exactement comme la spécification l'attend. L'option de longueur maximale de l'en-tête applique le budget de caractères que votre équipe a accepté (la valeur par défaut de commitlint est 72 caractères) ; forcer un début en minuscule et interdire un point final sont les deux règles de style que la plupart des linters de commit vérifient par défaut, et tous deux peuvent être désactivés si votre équipe ne les utilise pas.

En mode vérification, chaque ligne est traitée comme un en-tête de commit complet, donc coller la sortie de "git log --oneline" vérifie un lot entier à la fois. Choisissez si la sortie est un rapport — la ligne d'origine suivie de ce qui doit être corrigé — ou le message corrigé, avec minuscules automatiques et sans ponctuation où c'est sans équivoque. Une ligne qui ne suit pas du tout la forme type(scope): description est laissée intacte plutôt qu'être devinée.

Tout s'exécute dans votre navigateur, donc les messages de commit d'un référentiel privé ne quittent jamais votre appareil. Copiez le résultat, téléchargez-le en tant que fichier .txt ou renvoyez-le à l'entrée pour l'affiner davantage.

FAQ

Qu'est-ce qu'un Conventional Commit ?
Un message de commit écrit comme "type(scope): description", optionnellement suivi d'un corps et d'un pied de page. Des outils comme commitlint, semantic-release et les générateurs de changelog analysent ce format pour décider des changements de version et regrouper les notes de version.
Comment fonctionne le mode de vérification ?
Collez un message de commit par ligne — un en-tête uniquement, comme une ligne de "git log --oneline". Chaque ligne est validée selon la liste de types, la limite de longueur de l'en-tête et vos règles de minuscule/point, et est signalée séparément.
Comment marquer un changement important ?
Activez "Changement important" et ajoutez une note. L'en-tête obtient un "!" avant les deux points et, une fois la note non-vide, une ligne de pied de page "BREAKING CHANGE:" est ajoutée, correspondant exactement à la spécification de Conventional Commits.
Puis-je ajouter des références de tickets au pied de page ?
Oui — tapez dans le champ de pied de page, par exemple, "Ferme #123, refs JIRA-456". Il est ajouté en tant que sa propre ligne après le corps.
Mon historique de commits est-il téléchargé quelque part ?
Non. La construction et la vérification des messages de commit s'exécutent entièrement dans votre navigateur — rien de ce que vous tapez ou collez n'est envoyé à un serveur.