Cómo usar esta herramienta para desarrolladores
- Pega el mensaje completo del commit.
- Ajusta la longitud máxima y decide si solo aceptas tipos conocidos.
- Pulsa Validar commit.
- Corrige primero errores y después revisa las advertencias de estilo.
Conventional Commit Checker
Comprueba si un mensaje de commit sigue la estructura de Conventional Commits. Valida el tipo, el scope opcional, el indicador !, los dos puntos y la descripción. También avisa cuando la cabecera es demasiado larga o cuando el tipo no pertenece a una lista habitual, sin confundir una recomendación de estilo con un error sintáctico.
Datos de entrada
Mensaje de commitEspacio publicitario
Qué hace esta herramienta para desarrolladores
Distingue validez estructural de recomendaciones editoriales. Un mensaje puede ser sintácticamente válido y tener avisos sobre longitud, mayúscula inicial o pie de breaking change.
La cabecera se valida contra type(scope)!: descripción; el cuerpo se revisa por separado para localizar un pie BREAKING CHANGE.
Conventional Commits permite tipos definidos por el proyecto; desactiva “Exigir tipo conocido” si usas un vocabulario propio.
Ejemplo
feat(api)!: cambia el contrato reconoce tipo feat, scope api y breaking change.
Casos de uso
- Aplicar una política de commits antes de hacer push.
- Revisar mensajes copiados desde un PR.
- Enseñar la estructura Conventional Commits en un equipo.
- Detectar cabeceras excesivamente largas.
Consejos para obtener resultados fiables
- Usa tipos consistentes en todo el repositorio.
- Añade scope solo cuando aporte contexto estable.
- Describe el cambio en forma imperativa y concreta.
- Documenta breaking changes también en el cuerpo o pie.
Detalles del procesamiento
La herramienta evalúa únicamente texto. Los tipos conocidos usados por defecto son feat, fix, docs, style, refactor, perf, test, build, ci, chore y revert.
No sustituye a commitlint ni ejecuta hooks. Tampoco valida reglas personalizadas de un repositorio si no están representadas por las opciones visibles.
Preguntas frecuentes
¿Qué formato exacto valida el Conventional Commit Checker?
Valida una cabecera type(scope)!: descripción, con scope e indicador ! opcionales.
¿Puedo usar tipos personalizados además de feat y fix?
Sí. Desactiva la opción “Exigir tipo conocido” para aceptar cualquier tipo en minúsculas que cumpla la sintaxis.
¿Cómo detecta un breaking change en un commit?
Reconoce el signo ! en la cabecera y también busca un pie BREAKING CHANGE: o BREAKING-CHANGE: en el cuerpo.
¿Una cabecera de más de 72 caracteres hace inválido el commit?
Aquí se trata como advertencia configurable, no como error sintáctico obligatorio.
¿Esta validación reemplaza commitlint en CI?
No. Sirve para revisión local en el navegador; commitlint sigue siendo más adecuado para políticas automatizadas y reglas de proyecto.
Herramientas relacionadas para desarrolladores
Resumen de salida
| Elemento | Detalle |
|---|---|
| Sintaxis | type(scope)!: descripción |
| Tipos habituales | feat, fix, docs, refactor… |
| Breaking | ! y pie BREAKING CHANGE |
| Resultado | errores + avisos |
Explorar Git y repositorios
Consulta más utilidades para revisar commits, repositorios, historial y archivos de configuración de Git.
Ver categoría Git y repositorios