Generador de mensajes de commit
Crea un mensaje Conventional Commit limpio campo a campo: tipo, ámbito opcional, un asunto breve en imperativo, un cuerpo ajustado, una nota BREAKING CHANGE y referencias a issues. Cada regla se comprueba mientras escribes, y puedes copiar el mensaje o un comando git commit listo para ejecutar.
Última actualización:
Imperativo, en minúsculas, sin punto final. Completa la frase "If applied, this commit will …" (Si se aplica, este commit…)
Mensaje de commit
Comprobaciones
Resultado
Cómo usar Generador de mensajes de commit
- Elige el tipo que corresponde al cambio: feat para una función nueva, fix para corregir un error, docs, refactor, etc.
- Añade un ámbito (opcional) como api, auth o ui para indicar qué parte del código cambió.
- Escribe el asunto en modo imperativo, en minúsculas y sin punto final: "add password reset", no "Added password reset."
- Explica el porqué en el cuerpo si el cambio necesita contexto; luego marca Cambio incompatible y describe lo que deben hacer los usuarios si el cambio no es retrocompatible.
- Añade referencias a issues, revisa las comprobaciones y copia el mensaje o el comando git commit.
Formato Conventional Commit
La especificación Conventional Commits 1.0.0 estructura un mensaje de commit así:
<type>[optional scope][!]: <description> [optional body] [optional footer(s)]
- Encabezado: la única línea obligatoria. Un tipo, un ámbito opcional entre paréntesis, un
!opcional para cambios incompatibles, dos puntos, un espacio y una descripción breve. - Cuerpo: texto libre tras una línea en blanco. Explica qué cambió y por qué, no cómo; el diff ya muestra el cómo.
- Pies: tras otra línea en blanco, uno por línea con la forma
Token: valueoToken #value, comoBREAKING CHANGE: …,Refs: #123oCo-authored-by: Name <email>.
Tipos e incrementos de versión
| Tipo | Úsalo para | Ejemplo | Incremento SemVer* |
|---|---|---|---|
feat | Nuevas funciones para los usuarios | feat(cart): add coupon field | Menor (1.4.0 → 1.5.0) |
fix | Corrección de errores | fix(api): return 404 for unknown ids | Parche (1.4.0 → 1.4.1) |
perf | Mejoras de velocidad o memoria | perf: cache parsed templates | Parche |
refactor | Reestructuración sin cambiar el comportamiento | refactor(db): extract query builder | Ninguno |
docs | Solo documentación | docs: explain env variables in README | Ninguno |
style | Formato, espacios en blanco, correcciones de linting | style: apply prettier to src | Ninguno |
test | Añadir o corregir pruebas | test(auth): cover expired tokens | Ninguno |
build | Herramientas de compilación y dependencias | build(deps): bump vite to 5.4 | Ninguno |
ci | Pipelines y scripts de CI | ci: cache npm in GitHub Actions | Ninguno |
chore | Mantenimiento que no toca el código fuente ni las pruebas | chore: update .editorconfig | Ninguno |
revert | Deshacer un commit anterior | revert: feat(cart): add coupon field | Depende |
cualquier tipo + ! o BREAKING CHANGE: | Cambios que no son retrocompatibles | feat(api)!: drop v1 endpoints | Mayor (1.4.0 → 2.0.0) |
*Comportamiento predeterminado de semantic-release y standard-version con el preset Angular / conventional. Muchos equipos configuran perf, refactor o docs de otra forma.
Reglas de longitud que comprueba esta herramienta
- 50 caracteres para el encabezado es la pauta clásica (del proyecto Git y de "How to Write a Git Commit Message"): cabe en
git log --oneline, en las listas de commits de GitHub y en los asuntos de correo. - 72 caracteres es el límite estricto habitual para el encabezado y el ancho de ajuste de las líneas del cuerpo, porque
git logsangra el cuerpo 4 espacios y aun así debe caber en una terminal de 80 columnas. - 100 caracteres es el valor predeterminado de
header-max-lengthybody-max-line-lengthde commitlint en@commitlint/config-conventional; las líneas más largas no pasan el lint. Las URL no se cuentan, ya que no se pueden partir.
Consejo: si el asunto necesita la palabra "and" (y), probablemente el commit hace dos cosas. Dividirlo facilita las revisiones, las reversiones y git bisect. Para los comandos de Git que permiten enmendar, combinar o reescribir un commit, consulta la Chuleta de Git.
Preguntas frecuentes
¿Qué es un Conventional Commit?
Conventional Commits es una especificación ligera para mensajes de commit. La primera línea tiene la forma tipo(ámbito): descripción, por ejemplo fix(parser): handle empty input. Después de una línea en blanco pueden seguir párrafos opcionales de cuerpo y pie. Esta estructura permite que las herramientas generen registros de cambios y decidan automáticamente los incrementos de versión semántica.
¿Qué tipos de commit puedo usar?
La especificación en sí solo define feat y fix. El preset config-conventional de commitlint, muy utilizado y basado en la convención de Angular, también admite build, chore, ci, docs, perf, refactor, revert, style y test. Aquí se ofrecen esos 11 tipos.
¿Cómo marco un cambio incompatible?
Añade un signo de exclamación antes de los dos puntos, como en feat(api)!: remove v1 endpoints, y/o añade un pie que empiece por BREAKING CHANGE: seguido de una descripción. Un cambio incompatible provoca un incremento de versión mayor en semantic-release y herramientas similares, sea cual sea el tipo de commit.
¿Qué longitud debe tener el asunto de un commit?
Procura que toda la primera línea tenga 50 caracteres o menos para que se vea completa en git log --oneline, GitHub y la mayoría de herramientas. 72 caracteres es un límite estricto habitual, y el header-max-length predeterminado de commitlint es 100. Las líneas del cuerpo suelen ajustarse a 72 caracteres.
¿Por qué escribir el asunto en modo imperativo?
El propio Git escribe mensajes como Merge branch 'x' y Revert 'y', así que un asunto que completa la frase 'If applied, this commit will ...' (Si se aplica, este commit...) se lee de forma coherente: 'add login form', no 'added login form' ni 'adds login form'.
¿Cómo cierro un issue de GitHub o GitLab desde un commit?
Pon una palabra clave de cierre y el número del issue en el pie, por ejemplo Closes #42 o Fixes #42. GitHub cierra el issue cuando el commit llega a la rama predeterminada; GitLab admite las mismas palabras clave. Refs #42 enlaza el issue sin cerrarlo.
¿Cómo uso un mensaje de varias líneas con git commit?
Cada opción -m se convierte en su propio párrafo separado por una línea en blanco, así que git commit -m 'header' -m 'body' -m 'footer' produce un mensaje con el formato correcto. El comando generado usa esta forma con comillas seguras para Bash o PowerShell.
¿Se prueban todas las herramientas de FreeToolCabin para comprobar su calidad y precisión?
Sí. Cada herramienta del sitio pasa pruebas automáticas en navegadores reales para comprobar que el resultado es correcto y que no hay errores. Si encuentras un fallo o tienes una sugerencia, escríbenos a [email protected] y lo revisaremos.