Cómo cambiar el mensaje del último commit en Git (--amend)

Acabas de hacer commit, miras git log y ahí está: una errata en el mensaje, o directamente un texto que no explica nada. La buena noticia es que, si todavía no lo has subido a ningún sitio, cambiar el mensaje del último commit en Git es una sola orden: git commit --amend. No vas a romper el repositorio.

Para seguir este post necesitas saber hacer git add y git commit, y mirar tu historial con git log. Con eso basta. Y si tu duda de fondo es por qué importa que el mensaje esté bien escrito, ahí tienes la guía de buenas prácticas para mensajes de commit; aquí vamos a lo concreto: arreglar el que ya escribiste mal.

¿Cómo cambio el mensaje del último commit?

La orden directa es git commit --amend -m "nuevo mensaje". Con el flag -m le pasas el mensaje corregido en la misma línea y Git no te abre ningún editor.

Imagina que tu historial se ve así (el hash es ese código de siete letras y números al principio de cada línea, la matrícula única de cada commit):

# Miras el historial resumido, una línea por commit
$ git log --oneline
a1b2c3d Añdae función de login    # <- la errata: "Añdae"
9f3c1a2 Configura el proyecto

Corriges el mensaje del commit de arriba, el más reciente, así:

# Reescribe el mensaje del último commit
$ git commit --amend -m "Añade función de login"

# Vuelves a mirar: el mensaje ya está bien
$ git log --oneline
f4e5d6c Añade función de login    # <- mensaje corregido...
9f3c1a2 Configura el proyecto

Fíjate en un detalle raro: el hash ha cambiado. Antes empezaba por a1b2c3d y ahora por f4e5d6c. El commit anterior a este (9f3c1a2) sigue igual, pero el que tocaste tiene una matrícula nueva. Eso no es un fallo. Es la clave para entender qué acaba de pasar y por qué --amend tiene una regla de oro.

Qué hace --amend por dentro (y por qué cambia el hash)

git commit --amend no edita tu commit. Crea uno nuevo que sustituye al anterior ^[1]. El contenido de tus ficheros es idéntico, el commit padre es el mismo, pero para Git es un commit distinto con su propio hash.

¿Por qué? Porque ese hash no sale de la nada: es una huella calculada a partir de todo lo que forma el commit, y el mensaje forma parte de él. Cambia una sola letra del texto y la huella entera cambia. Un commit en Git es inmutable: no se puede modificar sin dejar de ser el mismo commit. Así que “editar el mensaje” es en realidad fabricar un commit gemelo con el texto corregido y apuntar tu rama a él.

El commit viejo, el de la errata, no se borra de inmediato. Queda ahí flotando, sin que nada apunte a él, y Git lo recuerda un tiempo en el reflog (más sobre esto en las preguntas de abajo). Pero para ti, a efectos prácticos, ha sido reemplazado.

Esto está muy bien mientras el commit viejo solo existía en tu ordenador. El problema aparece cuando ese commit ya vivía en otro sitio. Lo vemos en un momento.

¿Se me olvidó añadir un fichero al commit?

--amend no sirve solo para el mensaje. Sirve para rehacer el último commit entero, así que también lo usas cuando el mensaje estaba bien pero olvidaste incluir un fichero.

El truco está en el flag --no-edit, que le dice a Git: rehaz el commit con lo que hay ahora en el staging, pero deja el mensaje tal cual, sin abrir el editor ^[1].

# Añades el fichero que se te quedó fuera
$ git add estilos.css

# Rehaces el último commit incluyéndolo, sin tocar el mensaje
$ git commit --amend --no-edit

Ahora el fichero estilos.css forma parte de ese último commit, como si lo hubieras incluido desde el principio. El mensaje sigue siendo el mismo.

Un aviso importante aquí, porque es una trampa clásica de juniors. Puede que hayas visto por ahí el atajo git commit -a y pienses en usar git commit -a --amend para meter el fichero. No funciona con ficheros nuevos. El flag -a solo prepara automáticamente ficheros que Git ya está siguiendo y que has modificado o borrado; los ficheros nuevos, que Git todavía no conoce, no los toca ^[1]. Por eso el git add estilos.css explícito del ejemplo no sobra: es lo que mete el fichero nuevo en el commit.

Editar el mensaje en el editor (y salir de Vim)

Si escribes git commit --amend sin -m, Git abre un editor de texto con el mensaje actual ya escrito para que lo cambies con calma. Es más cómodo cuando el mensaje tiene varias líneas o quieres reescribirlo entero.

El susto típico es que ese editor sea Vim, y mucha gente se queda atrapada sin saber cómo salir. La receta para salir guardando: pulsa Esc, escribe :wq y pulsa Enter. Si prefieres no volver a pasar por esto, cambia el editor por defecto a uno más sencillo:

# Usa nano (o "code --wait" para VS Code) como editor de commits
$ git config --global core.editor "nano"

Guardas y cierras, y Git rehace el commit con el mensaje que dejaste. El resultado es el mismo que con -m: commit nuevo, hash nuevo.

Cuándo NO debes usar --amend

Aquí está la única regla que de verdad tienes que interiorizar: no hagas --amend de un commit que ya has subido a una rama que comparten otras personas.

Ya viste por qué. --amend no cambia el commit, lo reemplaza por otro con distinto hash. Si ese commit todavía solo estaba en tu máquina, a nadie le importa. Pero si ya lo habías subido a main (o a cualquier rama que tus compañeros tengan descargada), ellos tienen el commit viejo, con el hash viejo, y tú acabas de crear uno nuevo que dice ser “el mismo”. Cuando intenten sincronizar, sus repositorios y el tuyo discrepan sobre cuál es la historia real. Es un lío de conflictos y commits duplicados que arreglar a mano.

Reescribir la historia de una rama compartida es la forma más rápida de que tu equipo te mire mal un lunes por la mañana.

Esta tabla resume cuándo --amend es seguro y cuándo no:

Situación del commit	¿Puedo hacer --amend?	Qué hacer
Local, aún sin subir	Sí, sin miedo	git commit --amend y listo
Subido, pero a tu rama personal que nadie más usa	Con cuidado	--amend y luego git push --force-with-lease
Subido a main o a una rama compartida	No	Haz un commit nuevo de corrección

El caso del medio necesita un flag que te presento en la última sección, porque una vez que el commit ya está en el servidor un git push normal no basta.

¿Y si ya lo subí?

Depende de quién más tenga ese commit. Si la rama es tuya y estás seguro de que nadie más trabaja sobre ella, puedes forzar la subida del commit reescrito con git push --force-with-lease:

# Fuerzas la subida, pero solo si nadie ha tocado la rama remota entretanto
$ git push --force-with-lease

--force-with-lease es más seguro que --force a secas porque comprueba antes de empujar: si la rama remota ha avanzado desde tu último fetch (señal de que alguien más ha publicado algo), aborta el push en lugar de aplastar el trabajo ajeno ^[2]. Es más seguro, no es infalible: sigue reescribiendo historia, así que resérvalo para tus propias ramas.

Si la rama es compartida, olvídate del --amend. Lo limpio es dejar el commit malo donde está y añadir uno nuevo encima que corrija lo que haga falta. Nadie tiene que resincronizar nada y la historia sigue siendo coherente para todo el equipo. Si lo que quieres es deshacer el commit entero y no solo cambiar el texto, ese es otro camino: lo cuento en cómo deshacer el último commit en Git.

Y si Git te ha dejado el repositorio en un estado que no entiendes, la guía completa para deshacer cambios en Git recoge los casos más habituales para salir del apuro.

Antes de hacer --amend, comprueba

• El commit que vas a tocar es el último (HEAD), no uno de más atrás
• Ese commit todavía no está subido a una rama compartida
• Si olvidaste un fichero nuevo, hiciste git add de ese fichero antes del --amend
• Sabes que el hash va a cambiar y no pasa nada mientras el commit sea local
• Si ya lo subiste a tu rama personal, usarás --force-with-lease, nunca --force

Con eso tienes cubierto el 99% de los “ay, escribí mal el mensaje”. El resto de trucos de Git para arreglar la historia (rebase, reset, cherry-pick) los verás con calma y sin miedo en el curso Git de cero a profesional.

Fuentes

1. Documentación oficial de Git: git-commit. Comportamiento de --amend (crea un commit nuevo que reemplaza al anterior), --no-edit (mantiene el mensaje) y -a (solo prepara ficheros ya rastreados, no los nuevos).
2. Documentación oficial de Git: git-push. --force-with-lease aborta el push si la rama remota ha cambiado desde tu último fetch.

Preguntas Frecuentes

¿Al hacer --amend se borra mi commit anterior?

No exactamente. El commit anterior deja de estar referenciado (tu rama ahora apunta al commit nuevo), pero no desaparece al instante: queda “huérfano” y Git lo conserva un tiempo en el reflog antes de limpiarlo. Durante ese periodo puedes recuperarlo.

¿Cómo veo el mensaje viejo si me arrepiento del cambio?

Con git reflog. Ese comando lista todos los sitios donde ha estado HEAD recientemente, incluido el commit anterior al --amend con su hash. Copiando ese hash puedes volver a él o recuperar lo que necesites.

¿Puedo cambiar también el autor o la fecha del commit con --amend?

Sí. git commit --amend --author="Nombre <email@ejemplo.com>" cambia el autor, y --date cambia la fecha. Igual que con el mensaje, se genera un commit nuevo con distinto hash, así que aplica la misma regla: solo sobre commits que aún no hayas compartido.

¿git blame me muestra el mensaje del commit?

No. git blame te dice, línea a línea, qué commit tocó cada una, con su hash, su autor y su fecha, pero no imprime el mensaje. Para leer el mensaje de un commit concreto usas git show <hash> o lo buscas en git log.

Un concepto nuevo cada semana

Suscribirme