Cómo modificar la última confirmación en Git (mensaje, archivos, autor y deshacer)

Para corregir la confirmación más reciente en su rama actual, ejecute git commit --amend. Si no se prepara nada, Git reemplaza la confirmación con su mensaje actualizado; Si primero prepara nuevos cambios, Git incorpora esos cambios preparados en la confirmación y le permite mantener el mensaje existente con --no-edit o reescribirlo en su lugar. ¿Prefieres un flujo de trabajo visual? En GitTree en macOS, Windows y Linux, active Modificar confirmación anterior en el panel de confirmación (o haga clic con el botón derecho en la confirmación superior en el gráfico y elija Editar mensaje de confirmación...) para completar previamente el mensaje, preparar o cancelar líneas individuales, ver una advertencia de rama remota antes de reescribir el historial enviado y recuperar en cualquier momento con un solo clic Deshacer.

Referencia rápida: cada comando git commit --amend

Elija el comando exacto que coincida con lo que está mal en su última confirmación, o vaya a la sección detallada a continuación para ver casos extremos, ganchos, confirmaciones firmadas y alternativas visuales.

Lo que realmente hace git commit --amend bajo el capó

Cada hash de confirmación de Git es una suma de verificación criptográfica (SHA-1 o SHA-256) calculada a partir de cinco datos: la instantánea del árbol raíz, los hash de confirmación principales, el nombre/correo electrónico/marca de tiempo del autor, el nombre/correo electrónico/marca de tiempo del committor y el mensaje de confirmación. Cambie incluso un solo carácter en el mensaje (o la marca de tiempo del confirmador un segundo después) y el hash resultante será completamente diferente.

# Before git commit --amend:
A --- B --- C  <-- main (HEAD)

# After git commit --amend:
A --- B --- C' <-- main (HEAD)
       \
        C      (still in git reflog as HEAD@{1} until garbage collection)

Cuando ejecutas git commit --amend, Git toma lo que esté actualmente en el área de preparación (el índice), lo combina con los punteros principales de C (B), escribe un nuevo objeto de confirmación C' y actualiza tu referencia de rama actual para que apunte a C'. La confirmación original C no se elimina inmediatamente: permanece registrada en su registro local (HEAD@{1}) durante al menos 30 a 90 días (gc.reflogExpireUnreachable), razón por la cual una enmienda accidental siempre se puede recuperar localmente, ya sea a través de git reflog o mediante las herramientas Deshacer y rehacer y Objetos perdidos de GitTree.

1. Cambiar el último mensaje de confirmación.

Si acaba de cometerlo e inmediatamente notó un error tipográfico, un número de problema de Jira/GitHub incorrecto o un prefijo Conventional Commits faltante (feat:, fix:, chore:), verifique primero git status para saber si hay algo preparado.

Pase un nuevo mensaje de una línea o de varios párrafos con -m

Para reemplazar el mensaje directamente desde la terminal sin iniciar un editor, pase -m. Puede encadenar varios indicadores -m para crear una línea de asunto y párrafos de cuerpo:

# Replace the commit subject inline
git commit --amend -m "fix(auth): validate refresh token expiry before rotation"

# Replace both the subject line and body paragraph
git commit --amend \
  -m "fix(auth): validate refresh token expiry before rotation" \
  -m "Prevents expired tokens from issuing a new session when clock skew exceeds 30s."

Edite el mensaje existente en su editor de texto

Cuando su confirmación ya tenga una descripción detallada de varias líneas, avances (Co-authored-by:, Signed-off-by:) o referencias de problemas que no desee volver a escribir, ejecute git commit --amend sin -m:

git commit --amend

Git abre su core.editor configurado (Vim, Nano, VS Code, Zed, etc.) con el mensaje de confirmación actual precargado. Guarde y cierre el archivo para escribir la confirmación modificada. Si cambia de opinión mientras el editor está abierto, elimine todo el mensaje de confirmación (dejando el archivo vacío) y guárdelo: Git cancela la modificación con Aborting commit due to empty commit message y deja HEAD intacto.

2. Agregue archivos olvidados o líneas específicas a la última confirmación.

Olvidarse de guardar un archivo, preparar un dispositivo de prueba o ejecutar el formateador antes de confirmar es la razón más común por la que los desarrolladores recurren a --amend. Prepare primero los cambios que faltan y luego modifíquelos con --no-edit para que Git mantenga el mensaje de confirmación existente sin abrir un editor:

# Stage the forgotten file (or files)
git add src/auth/token-validator.test.ts

# Fold the staged file into the last commit and keep the existing message
git commit --amend --no-edit

Prepare solo líneas o fragmentos específicos antes de realizar modificaciones

¿Qué pasa si su árbol de trabajo contiene la corrección de 3 líneas que pertenece a la confirmación anterior *y* 40 líneas de registro de depuración o trabajo para su próxima característica? No ejecute git add . o git commit -a --amend. En su lugar, prepare solo los fragmentos o líneas exactos que pertenecen a la confirmación anterior usando el modo parche (que se explica en detalle en nuestra guía para git add -p y preparación de líneas específicas):

# Choose y/n/s (split) for each changed hunk
git add -p src/auth/token-validator.ts

# Verify what is staged vs what stays in the working tree
git diff --staged

# Amend the last commit with only the staged hunks
git commit --amend --no-edit

En GitTree, nunca tendrá que luchar con la división del fragmento de terminal (s, e) para hacer esto: haga clic en cualquier archivo en Cambios sin etapas, seleccione las líneas exactas o haga clic en Stage Hunk en la diferencia en línea o en paralelo, y active Modificar confirmación anterior. Consulte nuestra Guía de diferencias de Git para ver cómo la inspección de las diferencias preparadas y no preparadas evita que el código accidental se deslice en una confirmación modificada.

3. Eliminar un archivo cometido por error (sin eliminarlo del disco)

Supongamos que ejecutó git add . y confirmó accidentalmente un archivo .env.local, un artefacto de compilación grande o un archivo que pertenece a una solicitud de extracción separada. La forma de eliminarlo de HEAD depende de si el archivo existía en la confirmación antes de HEAD (HEAD~1) o se agregó recientemente en HEAD.

Caso A: eliminar un archivo recién agregado de la última confirmación (conservar el archivo local)

Utilice git rm --cached para eliminar el archivo del índice provisional mientras deja el archivo físico en su disco, luego modifique:

# Remove the file from the index only (leaves the file on disk)
git rm --cached .env.local

# Optional: add it to .gitignore so it never gets staged again
echo ".env.local" >> .gitignore
git add .gitignore

# Rewrite the last commit without .env.local
git commit --amend --no-edit

Caso B: revertir las ediciones de un archivo rastreado en la última confirmación (mantener las ediciones locales)

Si <file> ya fue rastreado en HEAD~1 y accidentalmente incluiste ediciones en HEAD, no uses git rm --cached (¡eso registraría la eliminación de un archivo en HEAD!). En su lugar, restaure la entrada de índice para ese archivo desde HEAD~1:

# Reset only the staged index state of <file> back to HEAD~1
git restore --source=HEAD~1 --staged src/config/database.ts

# Amend HEAD: the commit no longer touches database.ts, and your local edits stay in the working tree
git commit --amend --no-edit

Si, en cambio, desea descartar ediciones locales no deseadas o limpiar completamente los archivos sin seguimiento, consulte cómo descartar cambios y limpiar archivos sin seguimiento en Git y cómo restaurar un archivo eliminado en Git.

4. Cambie el autor, el correo electrónico o la marca de tiempo de la última confirmación.

Cuando realiza una confirmación en una computadora portátil nueva antes de configurar user.email, o realiza una confirmación dentro de un repositorio de trabajo mientras su correo electrónico personal GitHub está configurado globalmente, la confirmación registra la identidad incorrecta. git commit --amend puede reescribir los metadatos de la confirmación sin tocar un solo archivo.

# Option 1: Set an explicit author name and email on the last commit
git commit --amend --author="Jane Doe <jane@company.com>" --no-edit

# Option 2: Update git config first, then reset the commit author to match
git config user.name "Jane Doe"
git config user.email "jane@company.com"
git commit --amend --reset-author --no-edit

# Option 3: Amend the author date as well
git commit --amend --date="2026-11-11T14:30:00+02:00" --no-edit

5. Cómo modificar de forma segura una confirmación que ya impulsó

Tan pronto como modifica una confirmación que ya se envió a origin, su rama local y la rama de seguimiento remoto (origin/<branch>) divergen: su rama local tiene C', mientras que origin todavía tiene C. Ambas confirmaciones comparten el padre B.

Si la rama es tu propia característica o rama de solicitud de extracción, actualiza el remoto de forma segura con --force-with-lease (y --force-if-includes en Git 2.30+):

# Safely replace the remote branch tip with your amended commit
git push --force-with-lease --force-if-includes origin HEAD

• Por qué `--force-with-lease` en lugar de `--force`: git push --force simple sobrescribe ciegamente la rama remota, borrando cualquier confirmación que un compañero de equipo o un bot de CI haya enviado desde su última recuperación. --force-with-lease comprueba que origin/<branch> todavía apunte al SHA de confirmación exacto almacenado en su referencia de seguimiento remoto local; Mientras tanto, si alguien más presiona, Git rechaza el impulso en lugar de perder su trabajo.
• Qué agrega `--force-if-includes`: Si tiene habilitada la búsqueda automática en segundo plano, su referencia de seguimiento remoto podría actualizarse antes de enviar. --force-if-includes verifica que la confirmación en la punta de la rama remota se integró realmente en su reflog local antes de permitir la reescritura.
• Cuando estés en `main` o en una rama compartida: No modifiques ni fuerces el envío de una rama compartida en la que otros desarrolladores basan su trabajo. En su lugar, deje la confirmación intacta y envíe una nueva confirmación de corrección, o inviértala limpiamente con git revert (consulte nuestra guía para revertir confirmaciones y fusiones y el tutorial de recuperación de errores enviados).
• ¿Necesitas configurar tu rama de seguimiento primero? Consulta cómo configurar una rama ascendente en Git.

6. ¿Qué pasa si la confirmación que necesitas modificar NO es la última confirmación?

git commit --amend solo reescribe HEAD (la confirmación de sugerencia). Cuando el error tipográfico o el cambio faltante pertenece a HEAD~2 o tres confirmaciones anteriores, tienes dos opciones limpias, sin guardar ni seleccionar manualmente:

Opción 1: Autoquash CLI rápido con git commit --fixup

Prepare la solución, cree una confirmación --fixup dirigida al SHA de la confirmación anterior (o --fixup=amend:<sha> para editar también su mensaje) y ejecute git rebase -i --autosquash:

# 1. Stage the changes meant for the older commit (e.g. a1b2c3d)
git add src/api/client.ts

# 2. Create a fixup commit targeting a1b2c3d
git commit --fixup=a1b2c3d

# 3. Autosquash the fixup commit straight into a1b2c3d
GIT_SEQUENCE_EDITOR=: git rebase -i --autosquash a1b2c3d~1

Opción 2: Rebase interactivo visual en GitTree

En lugar de copiar SHA y editar archivos de tareas pendientes de rebase en la terminal, lea nuestra guía GUI de rebase interactiva y guía de rebase de ramas completas. En el planificador Rebase interactivo y Reescribir, aplastar y soltar de GitTree, haga clic con el botón derecho en cualquier confirmación anterior en el gráfico, elija Rebase interactiva desde aquí..., cambie esa confirmación a Reescribir o arrastre una confirmación de corrección a Fixup/Squash y aplíquela con un solo clic.

7. Cómo deshacer una confirmación accidental de git --amend

¿Ejecutó git commit --amend mientras se preparaban archivos no deseados o sobrescribió accidentalmente un mensaje de confirmación que necesitaba? Debido a que Git registra cada movimiento de HEAD en el registro local, su confirmación previa a la modificación todavía se encuentra segura en HEAD@{1}.

# 1. Inspect the reflog to see the amend and the commit before it
git reflog -n 5
# e9f8d7c (HEAD -> feature) HEAD@{0}: commit (amend): feat: add billing webhook
# 4a3b2c1 HEAD@{1}: commit: feat: add billing webhook

# 2. Restore the branch to the pre-amend commit and keep any extra changes staged
git reset --soft HEAD@{1}

El uso de git reset --soft HEAD@{1} coloca el puntero de rama nuevamente en la confirmación original (4a3b2c1) y deja la diferencia entre la confirmación modificada y la confirmación original preparada en su índice; no se pierde nada en su árbol de trabajo. Para profundizar en los restablecimientos de soft, mixed y hard y la recuperación de reflog, lea Git reset --soft vs --mixed vs --hard, cómo deshacer git reset, rebase o commit con reflog y cómo recuperar escondites caídos y confirmaciones pendientes.

Cuándo usar git commit --amend vs reset, revertir o rebase -i

Utilice esta matriz de decisión siempre que necesite arreglar el historial para elegir el comando que coincida con la posición de su commit y si sus compañeros de equipo lo han ejecutado:

Cómo GitTree elimina todos los errores comunes de git commit --amend

La mayoría de los accidentes de modificación de la línea de comandos ocurren porque la terminal oculta tres piezas críticas de contexto hasta que es demasiado tarde: lo que ya está en su área de preparación, si HEAD ya se ha enviado a origin y cuál era el SHA de confirmación anterior antes de sobrescribirlo. GitTree resuelve cada uno de esos modos de falla directamente en la interfaz:

• Inspección de diferencias en vivo por etapas y sin etapas: Antes de hacer clic en Modificar confirmación, la lista de Cambios por etapas se encuentra directamente encima del cuadro de confirmación para que nunca puedas doblar accidentalmente archivos a medio terminar en HEAD. Puede preparar o cancelar la preparación de líneas, fragmentos o archivos individuales con un solo clic (Preparar archivos, fragmentos y líneas).
• Detección de confirmación push y protección Force-Push-With-Lease: Cuando HEAD ya está en la rama remota, GitTree te advierte justo dentro del panel de confirmación *antes* de modificar y empareja el flujo de trabajo con Force Push (With Lease)… para que nunca sobrescribas la push de un compañero de equipo.
• Reformulación con clic derecho y creación rápida de `fixup!`/`amend!`: ¿Quieres reformular HEAD sin tocar tus archivos preparados? Haga clic derecho en la confirmación superior en el gráfico de confirmación y elija Editar mensaje de confirmación…. ¿Necesitas arreglar una confirmación anterior? Haga clic con el botón derecho en esa confirmación anterior en el gráfico para crear una confirmación fixup! o amend! o abra Rebase interactiva.
• Instantáneas de seguridad automáticas (`refs/ogt/trash`) y deshacer con un clic: Antes de ejecutar cualquiera de las 19 operaciones de cambio del historial, incluida Modificar una confirmación, rebase interactivo, restablecer, eliminar rama y descartar, GitTree registra una instantánea local en refs/ogt/trash. Al hacer clic en Deshacer (Cmd+Z / Ctrl+Z) se restaura inmediatamente el estado de preparación y confirmación previo a la modificación exacto.
• Terminal integrado y de objetos perdidos visuales: Incluso si modificó desde el terminal integrado o hace semanas, Lost & Found muestra confirmaciones inalcanzables y reemplazadas con sus diferencias completas para que pueda restaurarlas, seleccionarlas o bifurcarlas sin analizar la salida git reflog sin procesar.
• Ganchos de Git, advertencias secretas y mensajes de confirmación de IA: GitTree ejecuta los pre-commit y los commit-msg ganchos de Git de tu repositorio, verifica las diferencias preparadas para detectar claves API accidentales y (en GitTree Pro) permite que Nour genere mensajes de confirmación precisos usando tu propio agente de codificación local.