Tabla de contenidos
- Introducción
- Formato básico
- Cheatsheet y tendencias alternativas
- Beneficios
- Ejemplos narrativos
- Recursos recomendados
- Conclusión
Introducción
Cada célula de tu cuerpo se regenera. En siete años, tú, literalmente, ya no serás la misma persona. ¿Piensas que dentro de todo ese tiempo vas a recordar para qué servía ese commit que hiciste hoy? Ni tú, ni nadie.
Y sin embargo, seguimos escribiendo mensajes de commit como si los fuéramos a recordar para siempre. «Cambios menores», «arreglos varios», «últimos ajustes». Como si bastara con eso.
Este artículo es una invitación a cambiar eso. A escribir mensajes de commit que sí se entienden. Que cuentan una historia. Que ayudan a depurar, a colaborar, a crecer como desarrollador.
Formato básico
<tipo>(<scope>): <descripción>
- es opcional e indica el área afectada (por ejemplo,
api
,ui
,build
). - La <descripción> es una frase breve en tiempo presente, como un titular de periódico.
feat(login): permitir login con Google
Cheatsheet y tendencias alternativas
Tipos más usados
Tipo | ¿Cuándo usarlo? |
---|---|
feat | Nueva funcionalidad para el usuario |
fix | Corrección de errores |
docs | Cambios en documentación |
style | Cambios estéticos, sin afectar lógica |
refactor | Mejora interna sin cambiar funcionalidad |
test | Añadir o modificar pruebas |
chore | Tareas internas o de mantenimiento |
Otras tendencias en la comunidad
Conventional Commits
Base de muchas herramientas modernas (como Semantic Release).
- Ventajas: compatible con CI/CD, changelogs automáticos.
- Inconvenientes: puede sentirse burocrático si no se adapta bien.
Gitmoji
Combina semántica + emojis.
- Ejemplo:
✨ feat: nuevo componente de formulario
- Ventajas: más visual y expresivo.
- Inconvenientes: puede ser informal en ciertos contextos profesionales.
Prefijos personalizados
Definidos por el equipo según sus necesidades.
- Ejemplo:
UX:
,SEC:
,PERF:
- Ventajas: flexibilidad total.
- Inconvenientes: falta de estandarización y difícil integración con herramientas.
Beneficios
Historial que se entiende
En lugar de un caos de «update final», cada commit aporta contexto. Saber si un cambio arregla un bug o agrega una función nueva es inmediato.
Ayuda en emergencias
Viernes a las 18:00. El programa se ha roto. El cliente llama gritando. Cientos de usuarios reciben errores 500. Tienes que revisar 200 commits del equipo para encontrar qué lo provocó.
Encuentras uno que dice: modificaciones backend
. Lo abres. Diez minutos después descubres que solo borra imports y edita documentación.
En un universo paralelo, los commits tienen prefijos claros. Filtras con git log --grep=^fix
y encuentras la causa en segundos. El cliente, aliviado, hasta te invita una cerveza.
Automatización real
Los mensajes bien escritos permiten generar changelogs, etiquetas de versión, releases automáticas. No necesitas escribir todo eso a mano. Git lo hace por ti si tú escribes bien.
Mejora la colaboración
Tu commit no solo cuenta lo que cambiaste. Cuenta por qué, en qué parte, para qué. Y eso ahorra explicaciones innecesarias en cada Pull Request.
Ejemplos narrativos
fix(api): corregir error en validación de token vencido
feat(auth): permitir login con múltiples factores
docs(readme): añadir sección de troubleshooting
refactor(service): dividir lógica de negocio compleja
test(payments): pruebas con tarjetas fallidas
chore(ci): actualizar workflow de integración continua
Recursos recomendados
Conclusión
Un mensaje de commit es más que una obligación técnica. Es parte de la narrativa de un proyecto. Es una herramienta de comunicación. Una forma de trabajar mejor.
Así que la próxima vez que escribas git commit
, detente un segundo. Piensa en tu yo del futuro. Piensa en tu equipo. En el cliente desesperado. Y escribe el mensaje que te hubiera gustado leer en medio del caos.
Empieza hoy. Haz commits que se lean como documentación útil. Porque mañana —o dentro de siete años, lo vas a agradecer.