Vérifiez un message de commit selon Conventional Commits et commitlint, avec son incrément de version
Fonctionne dans votre navigateur. Rien de ce que vous saisissez n'est envoyé nulle part. Vérifié le 16 octobre 2026.Un conventional commit commence par un type, un scope facultatif et une description, par exemple "fix(api): handle empty response". Collez un message pour le vérifier avec les 12 règles de config-conventional de commitlint, voir ses parties et voir la version qu'il implique : feat donne minor, fix donne patch, un changement incompatible donne major.
Cette page a été traduite automatiquement à partir de l'original anglais. Aucune personne n’a encore relu la traduction : c’est la version anglaise qui fait foi. Lire l'original en anglais
Collez le message de commit, ou touchez un type comme feat ou fix pour en commencer un.
Lisez le résultat : chaque règle non respectée, en termes simples, avec les parties selon lesquelles le message a été lu.
Corrigez le message jusqu'à ce qu'il passe ; la ligne de version indique s'il implique une version major, minor ou patch.
Pour une pull request entière, passez à Une liste d'en-têtes et collez la sortie de git log --format=%s.
Conventional Commits est un petit format de messages de commit lisible par les outils : les outils de publication en déduisent le prochain numéro de version, et les outils de changelog le transforment en notes de version. De nombreuses équipes l'imposent avec commitlint dans un hook commit-msg, et un message de commit refusé est une petite frustration courante.
Le format. Un en-tête, puis un corps et des pieds facultatifs, séparés chacun par une ligne vide :
| Partie | Exemple | Règle |
|---|---|---|
| Type | feat, fix, docs |
L'un des 11, en minuscules |
| Scope | (api) |
Facultatif, entre parenthèses |
| Incompatible | ! avant les deux-points |
Ou un pied BREAKING CHANGE |
| Description | add login page |
Première lettre minuscule, sans point final |
| Longueur de l'en-tête | 100 caractères au maximum | |
| Pied | Closes #123 |
Après une ligne vide |
Ce qui est vérifié. Les douze règles de @commitlint/config-conventional : dix erreurs (type vide, casse du type, liste des types, description vide, casse de la description, point final, longueur de l'en-tête, espaces de l'en-tête, longueur des lignes du corps et du pied) et deux avertissements (une ligne vide avant le corps et avant le pied). Chaque échec est expliqué en termes simples, avec la correction.
L'incrément de version. La spécification associe les commits au versionnage sémantique (Semantic Versioning) : fix signifie une version patch, feat une version minor, et tout changement incompatible, marqué par ! ou par un pied BREAKING CHANGE, une version major. Les autres types comme docs ou chore ne changent pas la version à eux seuls.
Une pull request entière. Passez en mode liste et collez la sortie de git log --format=%s main..HEAD, un en-tête par ligne. Chaque en-tête passe ou échoue, et la version qui en résulte au total est indiquée.
Les réponses ont été vérifiées avec @commitlint/lint 19 et config-conventional sur plus de 100 messages. Tout s'exécute dans votre navigateur ; rien de ce que vous saisissez n'est envoyé nulle part.
Un message de commit dont la première ligne est un type, un scope facultatif entre parenthèses, deux-points, une espace et une courte description, par exemple fix(api): handle empty response. Le format vient de la spécification Conventional Commits 1.0.0, et les outils s'en servent pour choisir automatiquement le prochain numéro de version et rédiger les changelogs.
Utilisez feat pour un changement que les utilisateurs voient comme une nouvelle fonctionnalité, fix pour une correction de bug, et chore pour une maintenance qui ne change ni l'un ni l'autre, comme la mise à jour de dépendances. Les versions en découlent : feat produit une version minor, fix un patch, et chore aucune version à lui seul. docs, style, refactor, perf, test, build et ci sont les autres types standard.
Placez un point d'exclamation avant les deux-points, comme dans feat(api)!: remove the v1 endpoints, ou ajoutez après une ligne vide un pied qui commence par BREAKING CHANGE: et indique ce qui casse. L'un ou l'autre fait de la version une version major, quel que soit le type. Les deux ensemble sont permis et courants.
Généralement parce que l'en-tête ne correspond pas exactement à type: description, si bien que commitlint ne trouve ni type ni description. Causes fréquentes : une espace manquante après les deux-points, une espace avant, un type en majuscule ou inconnu, ou pas de type du tout. Collez le message ici pour voir quelle partie a été mal lue.
Pas avec config-conventional : sa règle subject-case refuse les descriptions en sentence case, start case, pascal case ou upper case, donc Add login échoue et add login passe. Le texte entre accents graves ou guillemets est ignoré pour cette règle, donc un nom comme `Button` au début ne pose pas de problème. Les équipes qui veulent des majuscules modifient la règle dans leur propre configuration.
Non. Par défaut, commitlint ignore les commits de merge, les reverts écrits par git, les commits fixup! et squash!, et les en-têtes qui ne sont qu'un numéro de version comme 1.2.3 ou chore(release): 1.2.3. Cette page ignore les mêmes messages et le signale, de sorte qu'une vérification ici donne la même réponse que le hook.
Les taux et les règles changent ; vérifiez la source avant de vous fier à un chiffre.
Toujours bloqué ? Poser une question sur Vérificateur de Conventional Commits et toute personne qui connaît la réponse peut répondre. Aucun compte nécessaire.