Construye un mensaje Conventional Commit
Conventional Commits es un formato para mensajes git que convierte el caos ("update", "fix stuff", "wip") en un historial legible. Cada commit empieza con un tipo (`feat`, `fix`, `docs`, `refactor`...), opcionalmente tiene un scope entre paréntesis (p. ej. `feat(auth):`), luego una descripción corta. Fácil de leer, fácil de automatizar.
Esta herramienta monta un mensaje de commit desde un formulario. Elige un tipo de la barra (11 tipos), escribe la descripción corta, opcionalmente añade un scope, body, breaking change (añade `!` tras el tipo y un footer `BREAKING CHANGE:`), footers (Closes #123, Co-authored-by, Signed-off-by).
Obtienes el resultado en tres formatos: texto plano (pega en el editor tras `git commit`), comando shell (`git commit -m "..."` con comillas escapadas), JSON (para bots como semantic-release).
Validación en vivo: descripción corta máx 72 caracteres (límite duro), sin punto al final, presente ("add" no "added").
Cómo usarlo
- Elige un tipo de commit en la barra superior. feat (nueva feature), fix (bug fix), docs (documentación), refactor (cambio de código sin cambio de comportamiento), perf (performance), test, build, ci, chore (limpieza pequeña), revert, style (formato).
- Scope (opcional): qué parte del codebase toca el commit, p. ej. `auth`, `api`, `ui`. Pulsa un chip preset o escribe el tuyo. Aparece entre paréntesis: `feat(auth): ...`.
- Descripción corta: una línea, máx 72 caracteres, sin punto al final, tiempo presente ("add login flow", no "added login flow"). El contador muestra la longitud, avisa cuando se supera el límite y cuando detecta tiempo pasado.
- Breaking change (Switch): activa si este commit rompe compatibilidad hacia atrás (cambio de API, feature eliminada, cambio de semántica). El generador añade `!` tras el tipo (`feat!:`) y un footer `BREAKING CHANGE: descripción`.
- Body (opcional): los detalles. Escribe el por qué aquí (contexto, motivación), no el qué (el diff ya lo muestra).
- Footers (opcional): añade filas con botones: Closes #123 (cierra un issue), Refs #456 (issue relacionado, no cierra), Co-authored-by (un segundo autor, p. ej. tras pair programming), Signed-off-by (DCO, Developer Certificate of Origin, requerido por proyectos como el kernel Linux), Reviewed-by, Custom (tu propia clave).
- Elige el formato de salida (Plano / Shell / JSON) y copia. Plano va al editor de git tras `git commit`. Shell va directo a la terminal. JSON alimenta a un bot CI o generador de changelog.
Cuándo es útil
Situaciones concretas en las que Conventional Commits cambia la calidad de un proyecto:
- Releases automáticos. semantic-release o release-please analizan los commits desde la última release. feat → bump minor (1.4.0 → 1.5.0). fix → bump patch (1.4.0 → 1.4.1). BREAKING CHANGE → bump major (1.4.0 → 2.0.0). Cero trabajo manual.
- CHANGELOG.md automático. Tras una release la herramienta genera una sección "Novedades en 1.5.0", agrupada en "Features", "Bug Fixes", "Performance Improvements". Cada línea enlaza al commit. También puedes hacerlo a mano con nuestro generador de changelog.
- Historial git legible. `git log --oneline` muestra "feat(auth): add magic link login", "fix(api): handle empty body", "docs: clarify install steps". No "update", "fix", "wip". Cada nuevo compañero entiende el historial de un vistazo.
- Revisión de código más rápida. El revisor ve el prefix y sabe si es un feat (mira tests, edge cases) o un refactor (mira de cerca, el comportamiento no debería haber cambiado). Pueden filtrar PRs por tipo.
- Plantillas PR y comprobaciones CI. Muchos proyectos (Vercel, Astro, Next.js) tienen validación CI de que el título del PR sea un Conventional Commit. Genera un título válido aquí para que el bot no te rebote.
- Trabajar en un monorepo. El scope en el commit (`feat(web):`, `fix(api):`) te dice en qué paquete/app está el cambio. Los changelogs los agrupan por separado.
Tras producir un batch de commits, usa el generador de CHANGELOG que agrupa commits por tipo. Y si estás construyendo un README de proyecto, la sección "Contribución" es un buen sitio para mencionar Conventional Commits, el generador de README tiene una plantilla lista.