Mantener los commits claros y consistentes no es solo estética: ayuda a entender el historial del proyecto y facilita la colaboración. Aquí tienes una guía práctica basada en Conventional Commits.

---

1. Estructura básica

<tipo>[alcance]: <mensaje breve>
[opcional: cuerpo del commit]
[opcional: footer]

• tipo → qué hace el commit (feat, fix, style, etc.)
• alcance → opcional, indica la parte del proyecto afectada (auth, cart, ui)
• mensaje breve → resumen de máximo ~50 caracteres, imperativo presente

Ejemplo mínimo:

feat: añadir buscador en la lista de productos

Ejemplo con cuerpo y footer:

refactor(auth): simplifica la lógica de validación de tokens

Se ha extraído la validación de tokens a un helper independiente
y se han añadido comentarios para mayor claridad.

BREAKING CHANGE: se elimina la función `validateOldToken`

---

2. Tipos de commits

Tipo	Cuándo usarlo	Ejemplo
feat	Nueva funcionalidad	feat: soporte login social
fix	Corrección de bug	fix: corrige cálculo de impuestos
docs	Documentación	docs: actualizar README con ejemplos API
style	Formato, limpieza, indentación (sin afectar lógica)	style: aplicar prettier en todos los archivos
refactor	Cambios internos sin añadir features ni fixes	refactor: extrae función de envío de emails
perf	Optimización de rendimiento	perf: optimiza consulta SQL de productos
test	Tests	test: añade pruebas unitarias para Button
chore	Mantenimiento, configuración, dependencias	chore: actualizar dependencias Node

💡 Para cambios de formato o limpieza, puedes usar tanto style: como refactor:.

---

3. Reglas prácticas

Mensaje breve

• Imperativo presente: “añade”, “corrige”, “actualiza”
• Sin punto final
• ~50 caracteres máximo

Ejemplo:

fix: corrige error en envío de formularios

Cuerpo del commit

• Explica por qué, no solo qué
• Líneas de ~72 caracteres

Ejemplo:

refactor: separar lógica de validación

Se ha movido validateInput a un helper independiente para
reutilización y tests más claros.

Footer

• Para notas especiales: BREAKING CHANGE, referencias a issues

BREAKING CHANGE: se elimina método antiguo de autenticación
Closes #123

Alcance (opcional)

• Indica área del proyecto afectada

feat(auth): login con Google
fix(cart): total incorrecto al eliminar producto

---

4. Verbos y tiempo

Para los mensajes de commit, la convención es usar el imperativo presente, que indica una acción directa. Esta regla sigue el estándar en inglés (add, fix, update). En español, puedes usar dos formas:

1. Infinitivo (interpretado como acción)

Esta es una opción común en la comunidad hispanohablante. El infinitivo se interpreta como una orden o acción a realizar por el commit.

• feat: añadir soporte para exportar PDF
• fix: corregir cálculo de impuestos

2. Imperativo real

Similar a la convención en inglés, puedes usar la forma imperativa directa.

• feat: agrega soporte para exportar PDF
• fix: corrige cálculo de impuestos

Ambas formas son válidas, pero lo más importante es que mantengas la consistencia en todo el proyecto.

¿Qué evitar?

Evita siempre el uso de verbos en otros tiempos, ya que rompen la convención de acción directa.

• Pasado: añadí, corregí
• Gerundio: añadiendo, corrigiendo
• Participio: añadido, corregido

---

5. Idioma

• Proyectos internos / equipo que habla español: puedes usar español en los commits. Ejemplo:

  feat: añadir soporte para exportar PDF
  fix: corregir cálculo de impuestos

• Proyectos públicos o colaborativos / open source: se recomienda inglés, porque es el estándar global y facilita contribuciones externas. Ejemplo:

  feat: add PDF export support
  fix: correct tax calculation

• En general, otra vez lo más importante es mantener consistencia: no mezclar español e inglés en el mismo proyecto.

---

6. Consejos finales

• Relaciona commits con issues (Closes #n)
• Divide commits grandes en partes lógicas
• Mantén consistencia en todo el equipo

---

7. Cheat sheet descargable

Para que tengas siempre a mano los tipos de commits y ejemplos prácticos, he preparado un cheat sheet que puedes consultar en gist o descargar en PDF: