Compruebe un mensaje de commit según Conventional Commits y commitlint, con su incremento de versión
Se ejecuta en su navegador. Nada de lo que escribe se envía a ningún sitio. Comprobado el 16 de octubre de 2026.Un conventional commit empieza con un tipo, un scope opcional y una descripción, como "fix(api): handle empty response". Pegue un mensaje para comprobarlo con las 12 reglas de config-conventional de commitlint, ver sus partes y ver la versión que implica: feat es minor, fix es patch y un cambio incompatible es major.
Esta página se ha traducido automáticamente del original en inglés. Ninguna persona ha revisado todavía la traducción, así que la versión en inglés es la que debe consultar. Leer el original en inglés
Pegue el mensaje de commit, o toque un tipo como feat o fix para empezar uno.
Lea el resultado: cada regla que incumple, en palabras sencillas, con las partes en que se interpretó el mensaje.
Corrija el mensaje hasta que pase; la línea de versión indica si implica una versión major, minor o patch.
Para un pull request completo, cambie a Una lista de encabezados y pegue la salida de git log --format=%s.
Conventional Commits es un formato breve para mensajes de commit que las herramientas pueden leer: las herramientas de publicación eligen con él el siguiente número de versión y las de changelog lo convierten en notas de la versión. Muchos equipos lo imponen con commitlint en un hook commit-msg, y un mensaje de commit rechazado es una pequeña molestia habitual.
El formato. Un encabezado y después un cuerpo y pies opcionales, separados cada uno por una línea en blanco:
| Parte | Ejemplo | Regla |
|---|---|---|
| Tipo | feat, fix, docs |
Uno de 11, en minúsculas |
| Scope | (api) |
Opcional, entre paréntesis |
| Incompatible | ! antes de los dos puntos |
O un pie BREAKING CHANGE |
| Descripción | add login page |
Primera letra minúscula, sin punto final |
| Longitud del encabezado | Como máximo 100 caracteres | |
| Pie | Closes #123 |
Tras una línea en blanco |
Qué comprueba. Las doce reglas de @commitlint/config-conventional: diez errores (tipo vacío, mayúsculas del tipo, lista de tipos, descripción vacía, mayúsculas de la descripción, punto final, longitud del encabezado, espacios en el encabezado, longitud de línea del cuerpo y del pie) y dos avisos (una línea en blanco antes del cuerpo y antes del pie). Cada fallo se explica en palabras sencillas con su corrección.
El incremento de versión. La especificación asocia los commits con el Versionado Semántico (Semantic Versioning): fix significa una versión patch, feat una minor, y cualquier cambio incompatible, marcado con ! o con un pie BREAKING CHANGE, una major. Otros tipos como docs o chore no cambian la versión por sí solos.
Un pull request completo. Cambie al modo de lista y pegue la salida de git log --format=%s main..HEAD, un encabezado por línea. Cada encabezado pasa o falla, y se indica la versión que resulta del conjunto.
Las respuestas se verificaron con @commitlint/lint 19 y config-conventional en más de 100 mensajes. Todo se ejecuta en su navegador; nada de lo que escribe se envía a ningún sitio.
Un mensaje de commit cuya primera línea es un tipo, un scope opcional entre paréntesis, dos puntos, un espacio y una descripción breve, como fix(api): handle empty response. El formato procede de la especificación Conventional Commits 1.0.0, y las herramientas lo usan para elegir el siguiente número de versión y redactar changelogs automáticamente.
Use feat para un cambio que los usuarios ven como una capacidad nueva, fix para la corrección de un error y chore para mantenimiento que no cambia ninguna de las dos cosas, como actualizar dependencias. Las versiones se derivan de ellos: feat genera una versión minor, fix una patch y chore ninguna por sí solo. docs, style, refactor, perf, test, build y ci son los otros tipos estándar.
Ponga un signo de exclamación antes de los dos puntos, como en feat(api)!: remove the v1 endpoints, o añada tras una línea en blanco un pie que empiece por BREAKING CHANGE: y diga qué se rompe. Cualquiera de los dos convierte la versión en major, sea cual sea el tipo. Ambos a la vez están permitidos y son habituales.
Normalmente porque el encabezado no coincide exactamente con type: description, así que commitlint no encuentra ni un tipo ni una descripción. Causas frecuentes son la falta de un espacio tras los dos puntos, un espacio antes de ellos, un tipo en mayúscula o desconocido, o ningún tipo. Pegue el mensaje aquí para ver qué parte se interpretó mal.
No con config-conventional: su regla subject-case rechaza descripciones en sentence case, start case, pascal case o upper case, por lo que Add login falla y add login pasa. El texto entre comillas invertidas o comillas se ignora para esta regla, así que un nombre como `Button` al principio no es problema. Los equipos que quieren mayúsculas cambian la regla en su propia configuración.
No. Por defecto commitlint omite los commits de merge, los reverts escritos por git, los commits fixup! y squash!, y los encabezados que son solo un número de versión, como 1.2.3 o chore(release): 1.2.3. Esta página omite los mismos mensajes y lo indica, de modo que una comprobación aquí da la misma respuesta que el hook.
Los tipos y las normas cambian; consulte la fuente antes de fiarse de una cifra.
¿Sigue sin resolverlo? Pregunte sobre Validador de Conventional Commits y cualquiera que lo sepa puede responder. No se necesita cuenta.