Hacer un commit parece una acción simple, pero en Git es una de las decisiones más importantes de todo el flujo de trabajo. Un commit no es solo “guardar cambios”: es una instantánea del proyecto con contexto, intención y trazabilidad. Si se hace bien, facilita revisar código, depurar errores y colaborar en equipo con menos fricción.
En esta guía vamos a centrarnos en cómo crear un commit correctamente con git commit, qué opciones conviene usar, cómo redactar mensajes útiles y qué errores evitar. Si todavía estás construyendo las bases de tu flujo, te puede venir bien repasar antes cómo crear tu primer repositorio con git init y cómo añadir archivos al repositorio con git add.
Qué hace realmente git commit
Cuando ejecutas git commit, Git toma el contenido que ya está en el área de preparación o staging area y lo convierte en un nuevo punto de historial. Eso significa que el commit no recoge automáticamente todos los cambios del directorio de trabajo, sino únicamente los que hayas preparado antes con git add.
Este detalle es clave porque te permite separar cambios lógicos. Por ejemplo, puedes crear un commit para corregir un bug y otro distinto para ajustar estilos o refactorizar una función. Esa separación mejora la revisión en pull requests y vuelve más fácil revertir una parte concreta del trabajo si algo falla.
Estructura básica del comando
La forma más habitual de crear un commit es esta:
git commit -m "Mensaje del commit"La opción -m te permite escribir un mensaje directamente en la línea de comandos. Es la forma más práctica cuando el mensaje es breve y claro. Si necesitas escribir una descripción más detallada, puedes dejar Git abrir tu editor predeterminado sin pasar -m.
Un ejemplo de uso real sería:
git add index.html estilos.css
git commit -m "Corrige el diseño de la cabecera en móvil"Cómo escribir un mensaje de commit útil
El mensaje de commit es, en la práctica, la nota que explica por qué existe ese cambio. Un buen mensaje ayuda a cualquiera a entender el historial sin tener que abrir cada archivo. Además, mejora mucho la experiencia cuando regresas al proyecto semanas después.
La recomendación más extendida es que el mensaje sea breve, específico y orientado a la acción. Evita textos genéricos como “cambios” o “update”. Aunque Git no obliga a seguir una convención, en equipos de desarrollo suele funcionar muy bien una estructura de tipo: verbo en presente + objeto + contexto.
Ejemplos de mensajes buenos y malos
Malos ejemplos:
git commit -m "cambios"
git commit -m "update"
git commit -m "arreglo varias cosas"Buenos ejemplos:
git commit -m "Añade validación al formulario de registro"
git commit -m "Corrige el cálculo del total en el carrito"
git commit -m "Elimina dependencias obsoletas del proyecto"Fíjate en que los buenos mensajes dicen qué se cambió y dan una pista del por qué. Esa pequeña diferencia ahorra mucho tiempo en revisión, mantenimiento y depuración.
Cuándo usar un commit y cuándo no
No todo cambio merece un commit inmediato. Si el trabajo está incompleto y no tiene sentido funcional, quizá convenga seguir modificando antes de cerrar una instantánea. En cambio, si ya has terminado una unidad lógica de trabajo, crear el commit cuanto antes suele ser la mejor opción.
Un criterio práctico es este: si pudieras explicar el cambio en una sola frase, probablemente ya tienes material suficiente para un commit. Esto también ayuda a mantener el historial limpio y evita commits gigantes que mezclan muchas lógicas distintas.
Dividir cambios grandes en commits pequeños
Una de las mejores prácticas en Git es crear commits pequeños y coherentes. No significa hacer commits excesivamente fragmentados, sino separar por intención. Por ejemplo:
git add src/login.js
git commit -m "Agrega validación del email"
git add src/login.css
git commit -m "Ajusta estilos del formulario de acceso"Ese enfoque favorece el desarrollo iterativo y reduce el riesgo de introducir errores difíciles de aislar. También mejora la revisión porque cada commit cuenta una historia más clara.
Opciones útiles de git commit
Además de -m, Git ofrece opciones muy conocidas que conviene entender desde el principio. No siempre las usarás en el día a día, pero forman parte del flujo profesional.
-a para incluir cambios de archivos ya rastreados
La opción -a permite incluir automáticamente los cambios de archivos que Git ya está siguiendo. Es útil para acelerar el proceso cuando solo has editado archivos versionados previamente.
git commit -a -m "Actualiza la lógica de permisos"Eso sí, no reemplaza a git add en todos los escenarios. Los archivos nuevos siguen necesitando ser añadidos manualmente al staging area. Si quieres reforzar esta parte del flujo, revisa antes cómo añadir archivos al repositorio con git add.
–amend para corregir el último commit
Si acabas de crear un commit y te das cuenta de que falta un archivo o el mensaje tiene un error, puedes usar –amend para modificar el último commit. Es una herramienta muy práctica, pero conviene usarla con cuidado si ya compartiste ese commit con otras personas.
git add archivo-faltante.txt
git commit --amend -m "Corrige la configuración inicial del despliegue"Este comando sustituye el commit más reciente por otro nuevo con el mismo propósito, pero con contenido actualizado. Es especialmente útil cuando estás trabajando localmente y todavía no has enviado cambios a un repositorio remoto.
Cómo comprobar que el commit se creó bien
Después de hacer un commit, siempre es buena idea revisar el historial y comprobar el estado del repositorio. Dos comandos muy usados para esto son git status y git log.
git status
git log --oneline --decorate --graphgit status te dice si te quedan cambios sin registrar. git log, por su parte, te muestra el historial de commits y te permite verificar que el mensaje quedó como esperabas.
Si estás aprendiendo Git desde cero, esta comprobación visual es clave para desarrollar confianza. También ayuda a conectar el funcionamiento del commit con lo que ya viste al entender qué es Git y para qué sirve.
Errores comunes al crear commits
Uno de los fallos más frecuentes es hacer commits demasiado grandes. Cuando un solo commit mezcla varias funcionalidades, correcciones y ajustes visuales, luego es más difícil identificar qué ha fallado. Otro error común es escribir mensajes poco informativos, que no aportan contexto.
También conviene evitar crear commits con archivos que no pertenecen a ese cambio. Por ejemplo, si estás corrigiendo un botón de la interfaz, no deberías incluir a la vez modificaciones de documentación o tareas pendientes sin relación directa.
Un último punto importante: no confundas “tener cambios” con “tener un commit listo”. Antes de ejecutar git commit, revisa que el staging area contenga solo lo necesario. Si aún no tienes claro cómo se seleccionan esos archivos, vuelve a repasar git add.
Flujo recomendado para crear commits limpios
Un flujo sencillo y efectivo suele ser este: modificas los archivos, revisas los cambios, añades solo lo necesario al staging area y finalmente creas el commit con un mensaje claro. Ese patrón reduce errores y hace que el historial del proyecto sea más legible.
# 1. Ver qué has cambiado
git status
# 2. Añadir solo los archivos relevantes
git add src/app.js src/app.css
# 3. Registrar el cambio con un mensaje útil
git commit -m "Mejora la accesibilidad del menú lateral"
# 4. Verificar el historial reciente
git log --oneline -n 3Este hábito es especialmente valioso en equipos donde varias personas trabajan sobre el mismo código. Un historial limpio no solo es más profesional: también acelera la colaboración, simplifica las revisiones y reduce el coste de mantenimiento.
Conclusión
Crear un commit correctamente con git commit no va solo de ejecutar un comando, sino de construir un historial útil, comprensible y sostenible. Si seleccionas bien los archivos, redactas mensajes claros y separas los cambios por intención, Git se convierte en una herramienta mucho más poderosa.
En otras palabras: un buen commit cuenta una historia. Y cuanto mejor esté contada, más fácil será desarrollar, revisar y mantener el proyecto a largo plazo.
Fuentes y lecturas recomendadas
Documentación oficial de git commit
Git book: Recording changes to the repository
Deja una respuesta