Por qué el commit es la pieza central de Git
Cada vez que guardas trabajo en Git estás creando un commit. Puede parecer un trámite rutinario, algo que se hace casi por reflejo al terminar una tarea, pero es la operación que define cómo se verá la historia de tu proyecto durante años. Un commit bien construido permite entender por qué cambió una línea de código, revertir un error sin dolor y colaborar con otras personas sin pisar su trabajo. Uno mal hecho convierte el historial en un cajón desordenado donde nadie encuentra nada.
El comando git commit toma los cambios que preparaste previamente y los registra en el repositorio local junto con un mensaje que describe qué hiciste. Esa combinación de contenido, metadatos y descripción forma una instantánea del proyecto que queda enlazada con las anteriores. A diferencia de un servicio de sincronización de archivos, Git no sobrescribe versiones: acumula una cadena de estados que puedes recorrer, comparar y combinar.
En esta guía revisaremos el comando a fondo con la versión estable actual de Git, la 2.56, publicada a finales de septiembre de 2026. Veremos las opciones que usarás a diario, cómo escribir mensajes de commit realmente útiles para tu equipo, cómo corregir errores después de confirmar, cómo agrupar varios commits en uno y qué herramientas recientes han aparecido para reescribir la historia con menos fricción. También dedicaremos secciones a los fallos habituales, a la seguridad y a casos prácticos que encontrarás en proyectos reales.
Antes de empezar, comprueba qué versión tienes instalada:
git --version
git version 2.56.0
Casi todo lo que se explica aquí funciona en versiones muy anteriores. Cuando una función dependa de una versión reciente, lo indicaremos expresamente.
Qué guarda exactamente un commit
Para usar bien un comando conviene entender qué hace por debajo. Un commit en Git es un objeto que contiene varias piezas de información:
- Una referencia a un árbol, que representa el estado completo de los archivos en ese momento.
- Una o más referencias a commits padre. El primer commit no tiene padre y un commit de fusión tiene dos o más.
- El autor, es decir, quién escribió originalmente el cambio, con su fecha.
- El confirmador o committer, que es quien aplicó el commit al repositorio, también con su fecha.
- El mensaje que describe el cambio.
Todo esto se resume en un identificador hash. Por defecto los repositorios siguen usando SHA-1, aunque el proyecto lleva varias versiones preparando la transición a SHA-256 de cara a Git 3.0. Puedes inspeccionar el contenido crudo de cualquier commit con git cat-file:
git cat-file -p HEAD
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
parent 9f2c1e7a3b5d8c0e4f6a1b2c3d4e5f60718293a4
author Laura Méndez <[email protected]> 1793103122 -0500
committer Laura Méndez <[email protected]> 1793103122 -0500
Agrega validación de correo en el formulario de registro
La consecuencia práctica más importante es que el hash depende de todo ese contenido. Si cambias el mensaje, el autor, la fecha o el padre, obtienes un commit distinto con un identificador distinto. Esto explica por qué “editar” un commit en realidad significa crear uno nuevo y por qué reescribir historia ya compartida causa problemas a otras personas.
El flujo básico de preparar y confirmar
Git separa el acto de elegir qué cambios quieres guardar del acto de guardarlos. Entre tu directorio de trabajo y el historial existe una zona intermedia llamada índice o área de preparación de Git, donde vas colocando exactamente lo que formará parte del siguiente commit. Esta separación es lo que te permite hacer commits pequeños y coherentes aunque hayas tocado muchos archivos a la vez.
Supongamos un proyecto pequeño con esta estructura:
tienda-api/
├── README.md
├── package.json
└── src/
├── app.js
├── rutas/
│ └── productos.js
└── utilidades/
└── validar.js
Has modificado productos.js y validar.js. El flujo habitual sería revisar el estado, preparar los archivos y confirmar:
git status
git add src/rutas/productos.js src/utilidades/validar.js
git commit -m "Valida el precio antes de crear un producto"
Si solo una parte de los cambios de un archivo pertenece a este commit, puedes preparar fragmentos concretos con el modo interactivo de git add:
git add -p src/rutas/productos.js
Git te mostrará cada bloque modificado y te preguntará si quieres incluirlo. Es una de las herramientas más infravaloradas para mantener commits limpios, porque evita mezclar una corrección de errores con un cambio de formato que hiciste de paso.
Escribir el mensaje en línea con la opción -m
La opción más utilizada es -m, que permite pasar el mensaje directamente en la línea de comandos. El texto va entre comillas y se coloca a continuación de la opción:
git commit -m "Corrige el cálculo de impuestos en pedidos internacionales"
La salida resume lo que acaba de ocurrir:
[main 3e7a9c1] Corrige el cálculo de impuestos en pedidos internacionales
2 files changed, 14 insertions(+), 3 deletions(-)
Entre corchetes aparece la rama actual y el hash abreviado del nuevo commit. Debajo, un resumen de archivos y líneas afectadas. En instalaciones nuevas la rama por defecto puede llamarse master o main según tu configuración; si quieres fijar main para todos los repositorios que inicialices, basta con esto:
git config --global init.defaultBranch main
Algo que mucha gente desconoce es que -m se puede repetir. Cada aparición crea un párrafo distinto, de modo que puedes escribir un asunto y un cuerpo sin abrir el editor:
git commit -m "Agrega caché a la consulta de categorías" \
-m "La consulta se ejecutaba en cada petición y suponía el 40 % del tiempo de respuesta. Se guarda el resultado durante cinco minutos."
Si omites -m por completo, Git abrirá tu editor configurado para que redactes el mensaje. Un commit sin mensaje se cancela automáticamente: Git no permite confirmar con la descripción vacía salvo que lo fuerces con --allow-empty-message, algo que prácticamente nunca deberías hacer.
Confirmar archivos rastreados con la opción -a
La opción -a le pide a Git que prepare automáticamente todos los archivos que ya están bajo control de versiones y que han sido modificados o eliminados, y que los incluya en el commit. Se suele combinar con -m:
git commit -am "Actualiza dependencias de desarrollo"
[main b81f0d4] Actualiza dependencias de desarrollo
2 files changed, 37 insertions(+), 29 deletions(-)
Hay un matiz importante: -a solo actúa sobre archivos que Git ya conoce. Si creaste un archivo nuevo, por ejemplo src/utilidades/formatear.js, no se incluirá. Para ver la diferencia, imagina este estado:
On branch main
Changes not staged for commit:
modified: src/app.js
Untracked files:
src/utilidades/formatear.js
Con git commit -am solo se confirmará app.js. El archivo nuevo seguirá sin rastrear hasta que ejecutes git add sobre él. Este comportamiento es intencionado: evita que archivos temporales, credenciales o artefactos de compilación entren en el historial por accidente.
La comodidad de -a tiene un coste. Al no pasar por el área de preparación, renuncias a decidir qué entra y qué no. Es útil cuando todos los cambios forman una única unidad lógica, pero si has tocado varias cosas sin relación, conviene preparar a mano.
Mensajes detallados desde el editor
Cuando un cambio necesita explicación, una sola línea se queda corta. Si ejecutas git commit sin -m, Git abre el editor configurado con una plantilla que incluye, en líneas comentadas, el resumen de lo que se va a confirmar. Escribes el mensaje, guardas, cierras y el commit se crea. Las líneas que empiezan por # se descartan.
Puedes elegir el editor con una variable de configuración:
git config --global core.editor "code --wait"
Otras opciones habituales son nano, vim o nvim. El parámetro --wait es necesario en editores gráficos para que Git espere a que cierres la pestaña antes de continuar.
Un mensaje completo se estructura así:
Limita los intentos de inicio de sesión por dirección IP
Tras cinco intentos fallidos en diez minutos, la API responde con
429 y bloquea nuevas peticiones durante quince minutos. El contador
se guarda en Redis para que funcione con varias instancias.
Se añade la variable LOGIN_MAX_INTENTOS para ajustar el límite
sin desplegar código nuevo.
Refs: #812
La primera línea actúa como asunto. Herramientas como git log --oneline, los correos generados por git format-patch o las interfaces de las plataformas de alojamiento muestran solo esa línea, así que debe entenderse por sí sola. Después va una línea en blanco obligatoria y luego el cuerpo, que explica el porqué y el contexto. Las plataformas como GitHub, GitLab o Forgejo enlazan automáticamente referencias del tipo #812 con la incidencia o solicitud de cambios correspondiente, lo que conecta el código con la discusión que lo originó.
Si tu equipo usa una estructura fija, puedes crear una plantilla propia y configurarla para que aparezca cada vez:
git config --global commit.template ~/.plantilla-commit.txt
Revisar el diff mientras redactas con -v
La opción -v o --verbose añade al final de la plantilla del editor el diff completo de lo que vas a confirmar. Ese diff no forma parte del mensaje final; Git lo coloca debajo de una línea de corte y lo descarta al guardar. Su utilidad es tener a la vista los cambios exactos mientras los describes.
git commit -v
En el editor verás algo parecido a esto:
# ------------------------ >8 ------------------------
# Do not modify or remove the line above.
# Everything below it will be ignored.
diff --git a/src/utilidades/validar.js b/src/utilidades/validar.js
index 1a2b3c4..5d6e7f8 100644
--- a/src/utilidades/validar.js
+++ b/src/utilidades/validar.js
@@ -12,6 +12,9 @@ export function validarPrecio(valor) {
+ if (Number.isNaN(valor)) {
+ throw new Error("El precio debe ser numérico");
+ }
Si te resulta útil siempre, actívala de forma permanente:
git config --global commit.verbose true
Esta pequeña ayuda tiene un efecto notable en la calidad de los mensajes, porque reduce las descripciones vagas del tipo “arreglos varios” que aparecen cuando no recuerdas qué cambiaste.
Corregir el último commit con –amend
Equivocarse justo después de confirmar es de lo más común: un error tipográfico en el mensaje, un archivo que olvidaste preparar o un console.log que se coló. La opción --amend existe precisamente para modificar el último commit sin crear uno adicional.
Para cambiar solo el mensaje:
git commit --amend -m "Valida el precio y el stock antes de crear un producto"
Para añadir un archivo olvidado manteniendo el mensaje original, se combina con --no-edit:
git add src/rutas/inventario.js
git commit --amend --no-edit
Y si quieres incluir el archivo y además retocar el mensaje en el editor, basta con omitir ambas opciones:
git add src/rutas/inventario.js
git commit --amend
Recuerda lo que vimos sobre los hashes: --amend no edita el commit anterior, sino que crea uno nuevo que lo sustituye en la punta de la rama. El original queda huérfano, aunque recuperable durante un tiempo gracias al reflog. Por eso la regla de oro es no enmendar commits que ya hayas enviado a una rama compartida. Si lo haces, la historia local y la remota divergen y el siguiente git push será rechazado.
Si el commit solo existe en una rama personal que nadie más usa, puedes enmendarlo y subirlo de nuevo con un envío forzado seguro:
git push --force-with-lease
La variante --force-with-lease es preferible a -f o --force porque comprueba que la rama remota sigue en el estado que esperas. Si alguien subió algo entretanto, el envío se rechaza en lugar de borrar su trabajo.
Cambiar el autor o la fecha de un commit
A veces el problema no está en el contenido, sino en la identidad. Ocurre al usar un equipo nuevo sin configurar, al confirmar con el correo personal en un repositorio de empresa o al aplicar un parche que escribió otra persona. Lo primero es configurar correctamente la identidad para que no vuelva a pasar:
git config --global user.name "Laura Méndez"
git config --global user.email "[email protected]"
Para corregir el último commit puedes pasar el autor explícitamente:
git commit --amend --no-edit --author="Laura Méndez <[email protected]>"
O, si ya corregiste la configuración, pedirle a Git que reinicie el autor con los valores actuales:
git commit --amend --no-edit --reset-author
--reset-author también actualiza la fecha de autoría. Si necesitas fijar una fecha concreta, por ejemplo al migrar historial, existe la opción --date:
git commit --amend --no-edit --date="2026-10-20T18:30:00"
Recuerda que autor y confirmador son campos distintos. --author cambia el primero; el segundo siempre toma tu configuración actual. Puedes ver ambos con git log --format=fuller.
Combinar varios commits en uno con rebase interactivo
Mientras trabajas en una funcionalidad es normal acumular commits intermedios: “primer intento”, “arreglo test”, “ahora sí”. Son útiles durante el desarrollo, pero aportan ruido cuando la rama se integra. El rebase interactivo te permite combinar varios commits en uno antes de compartirlos.
Para reorganizar los tres últimos commits:
git rebase -i HEAD~3
Git abre el editor con una lista de los commits, del más antiguo al más reciente:
pick 4c1d2e3 Agrega endpoint de reseñas
pick 7a8b9c0 Corrige validación de puntuación
pick e5f6a7b Ajusta mensajes de error
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup [-C | -c] <commit> = like "squash" but keep only the previous
# commit's log message
# d, drop <commit> = remove commit
Dejas el primero como pick y cambias los siguientes por squash (o su abreviatura s):
pick 4c1d2e3 Agrega endpoint de reseñas
squash 7a8b9c0 Corrige validación de puntuación
squash e5f6a7b Ajusta mensajes de error
Al guardar, Git combina los cambios y abre el editor de nuevo para que escribas el mensaje final a partir de los tres originales. Si prefieres descartar automáticamente los mensajes de los commits absorbidos, usa fixup en lugar de squash.
Los comentarios de la plantilla muestran más acciones: reword para cambiar solo un mensaje, edit para detenerte en un commit y modificar su contenido, drop para eliminarlo y la posibilidad de reordenar líneas para cambiar el orden de los commits. Vale la pena leerlos con calma la primera vez.
Como ocurre con --amend, combinar commits reescribe la historia. Si la rama ya estaba en el remoto, tendrás que subirla con git push --force-with-lease. En lugar de contar commits con HEAD~n, en una rama de funcionalidad suele ser más cómodo indicar la rama base:
git rebase -i main
Preparar correcciones con –fixup y –autosquash
Hay una forma más ordenada de llegar al mismo resultado sin editar listas a mano. Si descubres un fallo en un commit anterior de tu rama, puedes crear un commit de corrección que apunte a él:
git add src/rutas/resenas.js
git commit --fixup=4c1d2e3
Git genera un commit con un mensaje especial que empieza por fixup! seguido del asunto del commit original. Cuando llegue el momento de limpiar la rama, el rebase con --autosquash coloca cada corrección justo detrás de su objetivo y la marca para combinarse:
git rebase -i --autosquash main
Para no tener que recordar la opción, se puede activar por defecto:
git config --global rebase.autoSquash true
Existe además --fixup=reword:<commit>, que crea un commit vacío cuyo único propósito es sustituir el mensaje del commit indicado al hacer el rebase, y --squash=<commit>, que funciona igual que --fixup pero conserva el mensaje para editarlo. Este flujo es especialmente útil durante una revisión de código: cada comentario del revisor se resuelve con un commit fixup! fácil de revisar, y al final todo se integra limpiamente.
Alternativa reciente: el comando git history
Las últimas versiones de Git han incorporado un comando experimental llamado git history, pensado para las reescrituras más habituales sin tener que pasar por la lista del rebase interactivo. Llegó en Git 2.54 con los subcomandos reword y split, Git 2.55 añadió fixup y Git 2.56 incorporó drop, que elimina un commit concreto y vuelve a aplicar sus descendientes sobre el padre de ese commit.
Por ejemplo, para eliminar un commit que no debía estar en la rama:
git history drop 7a8b9c0
Y para cambiar el mensaje de un commit antiguo sin tocar su contenido:
git history reword 4c1d2e3
Al tratarse de una función experimental, su interfaz todavía puede cambiar entre versiones. Antes de incorporarla a scripts o a la documentación de tu equipo, consulta git help history en tu instalación. Para el trabajo cotidiano sigue siendo imprescindible dominar git rebase -i, que está disponible en cualquier versión y ofrece control total; git history es un atajo cómodo para casos puntuales.
Convenciones para escribir buenos mensajes
Un mensaje de commit es documentación que se lee meses o años después, normalmente cuando algo ha fallado y alguien intenta entender qué pasó. Estas pautas son ampliamente aceptadas:
- Mantén el asunto por debajo de unos 50 caracteres cuando sea posible, y nunca por encima de 72.
- Escribe el asunto en modo imperativo o descriptivo y de forma consistente: “Agrega”, “Corrige”, “Elimina”.
- No termines el asunto con punto.
- Separa asunto y cuerpo con una línea en blanco.
- Ajusta el cuerpo a unos 72 caracteres por línea para que se lea bien en terminal.
- Explica el porqué y el contexto en el cuerpo; el qué ya lo cuenta el diff.
Muchos equipos adoptan además la especificación Conventional Commits, que añade un prefijo con el tipo de cambio y, opcionalmente, un ámbito:
feat(pagos): permite reembolsos parciales
fix(auth): renueva el token antes de que expire
docs: documenta las variables de entorno obligatorias
refactor(pedidos): extrae el cálculo de envío a un servicio
La ventaja de esta convención es que la historia se vuelve legible por máquinas. Herramientas de publicación de versiones pueden generar notas de lanzamiento y decidir el siguiente número de versión semántica a partir de los prefijos. Para que el formato se respete, se suele validar con un hook commit-msg. Un ejemplo mínimo en Bash, guardado en .git/hooks/commit-msg con permisos de ejecución:
#!/usr/bin/env bash
patron='^(feat|fix|docs|refactor|test|chore|perf)(\([a-z0-9-]+\))?: .{1,72}$'
asunto=$(head -n 1 "$1")
if ! [[ "$asunto" =~ $patron ]]; then
echo "El asunto no sigue el formato tipo(ámbito): descripción" >&2
exit 1
fi
Si el hook termina con un código distinto de cero, Git cancela el commit y conserva el mensaje para que lo corrijas.
Otras opciones de git commit que conviene conocer
Más allá de las opciones clásicas, git commit incluye varias que resuelven situaciones concretas:
--dry-run: muestra qué se confirmaría sin crear el commit.--allow-empty: crea un commit sin cambios, útil para disparar una canalización de integración continua.-po--patch: abre la selección interactiva de fragmentos antes de confirmar, comogit add -p.-S: firma el commit con tu clave GPG o SSH.--no-verify: omite los hookspre-commitycommit-msg.-so--signoff: añade una líneaSigned-off-byal final del mensaje, habitual en proyectos que exigen el Developer Certificate of Origin.-C <commit>: reutiliza el mensaje y la autoría de otro commit.
Un ejemplo combinado, útil cuando la integración continua falló por un problema externo y necesitas relanzarla:
git commit --allow-empty -m "chore: relanza la canalización de CI"
git push
Y para revisar qué entraría en un commit con -a antes de hacerlo:
git commit -a --dry-run
Usa --no-verify con prudencia. Los hooks suelen existir por una razón, como ejecutar linters o detectar secretos filtrados, y saltárselos de forma habitual anula su propósito.
Errores comunes y cómo evitarlos
Algunos tropiezos se repiten tanto que merecen su propia lista.
El primero es confirmar archivos que nunca deberían estar en el repositorio: carpetas node_modules, archivos .env con credenciales o artefactos de compilación. La prevención es un .gitignore bien mantenido desde el primer día:
node_modules/
dist/
.env
.env.*
*.log
Si ya confirmaste un archivo y quieres dejar de rastrearlo sin borrarlo de tu disco:
git rm --cached .env
git commit -m "Deja de rastrear el archivo de variables de entorno"
Ojo: si ese archivo contenía credenciales y ya se subió al remoto, eliminarlo del último commit no basta. Las credenciales siguen en la historia y deben considerarse comprometidas. Hay que revocarlas y generar otras nuevas.
El segundo error frecuente son los commits gigantes que mezclan una funcionalidad, una refactorización y cambios de formato. Son difíciles de revisar y casi imposibles de revertir de forma selectiva. La solución es preparar por partes con git add -p y confirmar cada unidad lógica por separado.
El tercero son los mensajes sin contenido: “cambios”, “wip”, “arreglo”. Durante el desarrollo pueden servir como marcadores temporales, siempre que se limpien con rebase antes de integrar la rama.
El cuarto es enmendar o hacer rebase de commits que otras personas ya han descargado. Si trabajas en una rama compartida y necesitas deshacer algo, la opción segura es git revert, que crea un nuevo commit con los cambios inversos sin alterar la historia existente.
El quinto es olvidar en qué rama estás. Confirmar en main algo que debía ir en una rama de funcionalidad pasa a menudo. Mientras no hayas hecho push, se arregla fácilmente creando la rama en el punto actual y retrocediendo main:
git branch funcionalidad/resenas
git reset --hard HEAD~1
git switch funcionalidad/resenas
Solución de problemas frecuentes
Estos son los mensajes de error que más aparecen alrededor de git commit y cómo resolverlos.
Si intentas confirmar sin haber preparado nada:
On branch main
Changes not staged for commit:
modified: src/app.js
no changes added to commit (use "git add" and/or "git commit -a")
La solución es preparar los cambios con git add o usar -a si quieres incluir todos los archivos rastreados.
Si Git no sabe quién eres:
Author identity unknown
*** Please tell me who you are.
Configura user.name y user.email, globalmente o solo para ese repositorio quitando --global.
Si el editor se abre y no sabes salir, probablemente sea Vim. Escribe el mensaje tras pulsar i, después Esc y :wq para guardar y salir, o :cq para cancelar. A largo plazo, configura core.editor con un editor que te resulte cómodo.
Si un git push falla tras enmendar o hacer rebase:
! [rejected] funcionalidad/resenas -> funcionalidad/resenas (non-fast-forward)
error: failed to push some refs to 'origin'
Es la consecuencia esperada de reescribir historia. Si la rama es solo tuya, usa git push --force-with-lease. Si es compartida, coordina con el equipo antes de forzar nada.
Si un rebase interactivo se complica por conflictos, Git se detiene y te deja resolverlos. Después de editar los archivos, Git 2.56 ofrece git add --resolved, que prepara solo las rutas en conflicto ya resueltas sin arrastrar otros cambios locales. Luego continúa con git rebase --continue. Si prefieres abandonar y volver al estado previo:
git rebase --abort
Y si crees que has perdido un commit tras un --amend, un reset o un rebase, el reflog es tu red de seguridad:
git reflog
a1b2c3d HEAD@{0}: commit (amend): Valida el precio y el stock
f9e8d7c HEAD@{1}: commit: Valida el precio antes de crear un producto
Puedes recuperar el estado anterior creando una rama en ese punto con git branch rescate f9e8d7c.
Commits firmados y consideraciones de seguridad
Los campos de autor de un commit son texto libre. Cualquiera puede configurar el nombre y el correo de otra persona y confirmar en su nombre. Por eso muchos proyectos exigen commits firmados criptográficamente, que las plataformas de alojamiento marcan como verificados.
Además de GPG, Git admite firmar con claves SSH, lo que simplifica mucho la configuración porque probablemente ya tienes una:
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
A partir de ahí, cada commit se firma automáticamente. Puedes comprobar las firmas con:
git log --show-signature -1
Para verificar firmas SSH en local hay que indicar un archivo de firmantes permitidos mediante gpg.ssh.allowedSignersFile. Tras subir la clave pública a tu plataforma como clave de firma, los commits aparecerán como verificados en la interfaz web.
Otra medida importante es impedir que lleguen secretos al historial. Un hook pre-commit que ejecute un escáner de secretos detiene el commit antes de que se cree, que es el único momento en que el problema es barato de resolver. Una vez que la credencial está en un remoto, hay que darla por filtrada.
Comparativa entre amend, rebase, reset y revert
Todas estas herramientas sirven para corregir el pasado, pero no son intercambiables. Elegir bien depende de dos preguntas: qué quieres cambiar y si esa historia ya es compartida.
git commit --amend reemplaza el último commit. Es ideal para corregir el mensaje o añadir un archivo olvidado, siempre antes de hacer push a una rama compartida.
git rebase -i reescribe una serie de commits: los combina, reordena, elimina o renombra. Es la herramienta para dejar un historial de commits limpio antes de integrar una rama de funcionalidad.
git reset mueve la punta de la rama hacia atrás. Con --soft conserva los cambios preparados, con --mixed los deja sin preparar y con --hard los descarta. Por ejemplo, para deshacer el último commit pero mantener su contenido listo para volver a confirmar:
git reset --soft HEAD~1
git revert crea un nuevo commit que deshace los cambios de otro. No reescribe nada, así que es la única opción segura en ramas compartidas como main:
git revert 3e7a9c1
Como regla práctica: en tu rama local usa --amend, rebase o reset con libertad; en ramas compartidas, revert.
Casos de uso reales
Veamos cómo se combinan estas piezas en situaciones cotidianas.
En una rama de funcionalidad con revisión de código, el desarrollador trabaja con commits pequeños, recibe comentarios, los resuelve con git commit --fixup y, cuando la revisión se aprueba, ejecuta git rebase -i --autosquash main para integrar una historia ordenada. Muchas plataformas ofrecen además la fusión con squash, que reduce toda la rama a un único commit al integrarla; es cómoda, pero pierde el detalle de los pasos intermedios, así que conviene decidir en equipo qué estrategia se prefiere.
En un proyecto de código abierto que exige el certificado de origen, cada contribución incluye la línea de aprobación:
git commit -s -m "fix(parser): maneja comentarios al final del archivo"
En un equipo que publica versiones automáticamente, los mensajes siguen Conventional Commits y la herramienta de publicación decide si el siguiente lanzamiento es un parche, una versión menor o una mayor según los prefijos fix, feat o los cambios marcados como incompatibles.
En una investigación de un fallo en producción, un historial con commits atómicos permite usar git bisect para localizar el commit exacto que introdujo el problema. Git 2.56 incluso limpia automáticamente el estado al terminar git bisect run. Con commits pequeños y bien descritos, el resultado de la búsqueda explica por sí mismo qué cambió y por qué, y revertirlo es inmediato.
Conclusiones
git commit es mucho más que la orden que guarda tu trabajo. Es la forma en que construyes, paso a paso, la memoria del proyecto. Las opciones básicas como -m y -a cubren el día a día, pero dominar --amend, --fixup, el rebase interactivo y, en las versiones recientes, el comando experimental git history te da control para corregir errores antes de que lleguen a otras personas.
Las ideas clave son pocas: prepara con intención usando el área de preparación, haz commits pequeños que representen una sola unidad lógica, escribe mensajes que expliquen el porqué, reescribe la historia solo mientras sea tuya y usa revert cuando ya sea compartida. Complementa todo ello con firmas, hooks y un .gitignore cuidado para proteger el repositorio.
Con Git 2.56 como versión estable actual y Git 3.0 en el horizonte, las herramientas para trabajar con la historia siguen mejorando. Los fundamentos, sin embargo, se mantienen: un buen commit es aquel que tu yo del futuro, o cualquier compañero, puede leer y entender sin necesidad de preguntar.