Cuando trabajamos en un proyecto con Git, los mensajes de commit suelen convertirse en un caos:
unos escriben “fix”, otros “cambios varios”, otros “arreglos”, y al final nadie sabe realmente qué pasó en cada parte del código.

Para solucionar este problema nació Conventional Commits, una convención que estandariza cómo deben escribirse los mensajes de commit.

¿Qué son los Conventional Commits?

Conventional Commits es una especificación que define un formato estándar para los mensajes de commit en Git.
Su objetivo es:

• Hacer el historial de commits más legible y claro.
• Permitir automatización, como generar changelogs o versionado semántico.
• Mejorar la colaboración en equipos al seguir un mismo estilo.

Estructura básica de un commit convencional

La estructura mínima es:

<tipo>(<alcance opcional>): <descripción breve>

Ejemplo:

feat(auth): add Google login
fix(api): fix user validation error
docs(readme): update installation guide

Tipos más comunes de commits

• feat → nueva funcionalidad.
• fix → corrección de errores.
• docs → cambios en documentación.
• style → cambios de formato (espacios, indentación, comas).
• refactor → cambios internos que no afectan funcionalidad.
• test → cambios o adiciones en pruebas.
• chore → tareas de mantenimiento (dependencias, build, etc.).

Ejemplo con un header de landing page

Supongamos que estás desarrollando el header de tu landing page.
Tus commits podrían verse así:

En inglés:

feat(header): add initial landing page header

En español(Solo como ejemplo):

feat(header): crear header inicial para la landing page

Si luego corriges un bug de diseño:

fix(header): fix logo alignment on small screens

O si solo ajustas estilos:

style(header): adjust spacing between navigation links<br>

Títulos y descripciones

El título es obligatorio, pero también puedes añadir una descripción (body) para dar más contexto.

Ejemplo en inglés:

feat(header): add initial landing page header

Created the main header component with logo placeholder and navigation links.
This will be the base structure for the landing page and will be improved
with responsive design in the next steps.

Ejemplo en español:

feat(header): crear header inicial para la landing page

Se creó el componente principal del header con un logo de prueba
y enlaces de navegación. Este será la base de la landing page
y se mejorará con diseño responsive en los siguientes pasos.

Footer opcional

El footer se usa para:

• Referencias a issues: fix(header): fix logo alignment Closes #45
• Breaking changes: feat(api): add authentication middleware BREAKING CHANGE: all requests now require authentication

Beneficios de usar Conventional Commits

1. Claridad en el historial → todos entienden qué cambió.
2. Automatización → con herramientas como Commitlint o Semantic Release, puedes:
   • Validar mensajes de commit.
   • Generar changelogs automáticos.
   • Actualizar versiones según semver (ej. fix → patch, feat → minor, BREAKING CHANGE → major).
3. Trabajo en equipo más ordenado

Conclusión

Adoptar Conventional Commits en tu flujo de trabajo hace que tus commits dejen de ser simples notas y se conviertan en una fuente estructurada de información.

Ya sea que trabajes solo o en equipo, esta convención mejora la comunicación, facilita la automatización y mantiene tu proyecto escalable en el tiempo.