El estándar Conventional Commits
Conventional Commits (conventionalcommits.org) define un formato para mensajes de commit:
<type>(<scope>): <subject>, opcionalmente seguido por un
body y un footer. Es la convención más adoptada en proyectos open source y en empresas
grandes para automatizar versionado y changelogs.
La línea subject
Máximo 50-72 caracteres, en imperativo presente: "add" en lugar de "added" o "adds". Sin punto final. Empieza con minúscula. La regla mnemotécnica: si tu mensaje completa la frase "If applied, this commit will...", el verbo en imperativo encaja: "if applied, this commit will add login flow".
Tipos y cuándo usarlos
- feat: nueva funcionalidad para el usuario.
- fix: corrección de bug.
- docs: solo documentación.
- style: formato (espacios, punto y coma); no cambia comportamiento.
- refactor: cambio interno sin nueva feature ni fix.
- perf: mejora de performance.
- test: agregar o corregir tests.
- build: cambios al sistema de build o dependencias.
- ci: cambios en pipelines de CI.
- chore: tareas auxiliares que no caen en lo anterior.
- revert: revertir un commit anterior.
Scope: opcional pero útil
El scope identifica el área del código afectada. feat(auth) es más legible
que feat a secas. Convenciones comunes: nombre del módulo (auth,
billing), nombre del paquete en monorepos, o componente UI
(button, nav).
Breaking changes
Hay dos formas de marcar un breaking change. La corta: feat(api)!: rename user
endpoints. La explícita: agregás un footer BREAKING CHANGE: la ruta
/users/me ahora es /me. Las herramientas de versionado disparan un major bump
cuando detectan cualquiera de las dos.
Body y footer
El body explica el "por qué" cuando el subject no alcanza. Separá con una línea en blanco.
Los footers van al final: Closes #123, Co-authored-by: Name
<email>, Refs: JIRA-456. Useable por bots y automatizaciones.
Beneficios concretos
Con commits convencionales, herramientas como standard-version o
semantic-release generan automáticamente: changelog desde Markdown, tag de
versión, release en GitHub. Se acabó el "alguien tiene que escribir el changelog".
Cómo enforzar
Hooks con commitlint + Husky validan cada commit. PR templates recuerdan el
formato. En proyectos grandes, configurar la regla en CI evita que se mergeen commits que
rompen la convención. Squash merges pueden reescribir el mensaje al combinar.