Hemos visto que Git es una herramienta de gestión de versiones donde podemos guardar “fotocopias” de nuestro proyecto a medida que avanzamos.
Un Commit es, precisamente, cada una de esas “operaciones de guardado”. El Commit es la operación más importante del sistema Git.
Pero, a diferencia del clásico Ctrl + S de un editor de texto, un :[Commit] es un paquete inmutable que registra y captura el estado de tu proyecto en el tiempo.
En este artículo vamos a ver cómo crear estos puntos de guardado, cómo estructurar los mensajes asociados que expliquen la historia de tu código..
¿Qué es realmente un Commit?
Técnicamente, un commit es un objeto que contiene:
- Una instantánea (snapshot) de todo tu proyecto en ese momento.
- Unos metadatos: Autor, fecha y un mensaje explicativo.
- Un puntero al commit anterior (su padre).
Gracias a este puntero al padre, Git puede construir la historia como una cadena de eslabones. El commit actual sabe de dónde viene, y así sucesivamente hasta el principio de los tiempos (init).
Creando tu primer commit
La forma de crear un commit es (se ve venir), es el commando commit. La sintaxis más habitual y rápida es usando la opción -m (message) para escribir la descripción directamente en la línea de comandos.
git commit -m "Crear estructura inicial del proyecto"
Si todo ha ido bien, Git te responderá con algo así:
[main (root-commit) 834a9b1] Crear estructura inicial del proyecto 3 files changed, 55 insertions(+)
¡Ya está! Tus cambios están grabados a fuego en la base de datos de Git. Ya están seguros.
Los diagramas de “Pelotitas”
El concepto de commit es tan central en Git, que toda la industria ha adoptado la misma forma visual para representarlos: los diagramas de grafos (a.k.a los “diagramas de pelotitas”).
Cada uno de esos círculos representa una de esas “fotocopias” inmutables con su código, su autor y su mensaje. La línea que los une es la historia de tu proyecto avanzando en el tiempo.
Iremos usando este tipo de grafos en el curso para explicar los futuros conceptos.
Buenas prácticas en los mensajes
El mensaje del commit es una herramienta muy importante para la trazabilidad. Un historial lleno de mensajes como “fix”, “cambios”, “asdf” o “update” no es muy útil.
Cuando algo se rompa dentro de un año y tengas que buscar cuándo pasó, agradecerás haber escrito mensajes claros.
Hay mucho fanatismo alrededor de los mensajes de commit. A menudo se enseña que absolutamente todos los commits deben tener un mensaje perfecto y literario. Yo os cuento la teoría, y al final os doy mi opinión.
La teoría perfecta
Si consultas la documentación oficial, un mensaje de commit “perfecto” debería tener esta estructura:
Resumen corto de los cambios (máx 50 caracteres)
Cuerpo del mensaje más detallado, explicando QUÉ y POR QUÉ
se hizo este cambio. No expliques CÓMO (eso se ve en el código).
Puedes usar varias líneas.
Aunque siendo realistas, para el 95% de los commits del día a día, una única línea de resumen clara y descriptiva es más que suficiente.
Por otro lado se recomienda que, para mantener la coherencia, es muy conveniente seguir estas tres directrices:
Escribe el mensaje como si estuvieras dando una orden o completando la frase: “Si aplico este commit, va a…”
- ❌ Mal: “Añadido botón de login” (Pasado)
- ❌ Mal: “Añadiendo botón de login” (Gerundio)
- ✅ Bien: “Añadir botón de login” (Imperativo)
En inglés es más evidente (Add vs Added), pero en español mantenemos el infinitivo/imperativo para ser consistentes.
El mensaje debe describir el cambio sin tener que abrir el código.
- ❌ Mal: “Arreglar bug” (¿Cuál de los 200 bugs?)
- ❌ Mal: “Cambios en estilos”
- ✅ Bien: “Corregir desbordamiento en el menú móvil”
- ✅ Bien: “Actualizar color primario a azul corporativo”
Esta es una práctica muy extendida (y obligatoria en muchas empresas). Consiste en poner un prefijo que indique el tipo de cambio:
feat:Para una nueva funcionalidad (feature).fix:Para corregir un error.docs:Cambios solo en documentación.style:Cambios de formato (espacios, puntos y coma) que no afectan al código.refactor:Cambios en el código que no añaden funcionalidad ni arreglan bugs, solo mejoran la estructura.
Ejemplos:
feat: añadir soporte para modo oscurofix: evitar crash al dividir por cerodocs: actualizar instrucciones en el README
Como decía, hay mucho fanatismo alrededor de los mensajes de commit, con el que no estoy del todo de acuerdo. No todos los commit necesitan un gran mensaje.
Lo verdaderamente importante es que Git sea una herramienta útil y práctica para ti, y para tu equipo. Si para no perder tu trabajo necesitas hacer tres commits intermedios “de baja entidad” con mensajes rápidos como “update”, hazlos.
Más adelante aprenderemos técnicas como el uso de ramas, y técnicas como Squash para coger todos esos commits “sucios” de tu rama y fusionarlos en un único commit perfecto antes de compartirlos con el resto del equipo.
El historial perfecto se exige cuando integras tu trabajo en las ramas principales, no mientras estás experimentando en tu espacio personal.
