Git School · FluxGit

Git amend: corrige el último commit sin sorpresas

FluxGit ·

Los bloques son casos distintos, no un único script. Elige el que encaja con tu repositorio. Sustituye ramas, rutas y VERIFIED_COMMIT antes de usarlos. Los comandos de cancelación solo corresponden a su operación activa; no ejecutes ambas alternativas.

Respuesta breve

Commit --amend reemplaza la punta actual por un commit nuevo; no modifica el objeto original. Sirve para corregir mensaje o contenido del último commit local tras revisar lo preparado. Si otras personas ya recibieron el commit, una corrección adicional suele ser más fácil de coordinar que reescribir su historial.

Ejemplo y condiciones

El ejemplo usa un commit local normal con un mensaje mal escrito y un cambio omitido en src/parser.js. Son dos reparaciones: solo mensaje, o contenido también. No es un ejemplo para commits anteriores, el commit inicial o un merge. Sustituye el archivo y el mensaje por los tuyos y parte de la punta actual.

Inspecciona antes de cambiar

Revisa status, el último commit y diff --cached. El índice aporta contenido a un amend normal: archivos preparados de otra tarea pueden entrar por sorpresa. Inspecciona también lo no preparado para distinguir qué queda fuera. Comprueba si el original fue publicado, integrado o utilizado por otra persona antes de cambiar su identidad.

git status --short
git log -1 --oneline
git diff --cached
git diff

Conserva una referencia o checkout separado

Crea rescue/before-amend en HEAD para conservar el objeto original y compararlo. No guarda todos los archivos locales: conserva aparte los que lo necesiten. Reflog puede ayudar mientras se retenga localmente, pero no garantiza la conservación permanente de objetos ni respalda modificaciones que nunca se confirmaron.

git branch rescue/before-amend HEAD

Primer flujo

Para corregir solo el mensaje, --amend --only sin rutas excluye cambios que ya estaban preparados. -m proporciona el mensaje corregido. Inspecciona después el commit y el índice: el trabajo preparado debe seguir disponible para otro commit. Incluir también contenido preparado es el otro flujo, aunque ambos comandos contengan --amend.

git commit --amend --only -m "Fix parser error message"
git diff --cached

Elige deliberadamente la otra opción

Para un archivo omitido, prepara la ruta pertinente, revisa todo el diff preparado y usa --amend --no-edit para conservar el mensaje. Otros archivos preparados también entran si no los excluyes deliberadamente. Ejecuta las comprobaciones del proyecto. Preparar hunks concretos ayuda a revisar, pero no demuestra que el commit final combinado sea correcto.

git add -- src/parser.js
git diff --cached
git commit --amend --no-edit

Límites y excepciones

Si la punta se compartió, prefiere un commit nuevo de corrección encima. Publicar una punta reescrita puede exigir coordinación y estar prohibido por la protección de rama. Esta guía no da un force push genérico. Si el equipo autoriza una reescritura, sigue aparte su política de lease, rama y comprobaciones con colaboradores.

git add -- src/parser.js
git diff --cached
git commit -m "Correct parser handling"

Conflictos y limpieza

Amend normalmente no tiene un proceso propio de resolución de conflictos. Un hook fallido o un commit rechazado requiere revisar mensaje y estado, no ejecutar reset --hard automáticamente. Si incluiste contenido equivocado, compáralo primero con rescue/before-amend. Conserva copias comprobadas de archivos locales antes de cualquier reset correctivo.

Verifica el resultado

Compara archivos y mensaje del commit original y del nuevo. Sus IDs deben diferir. Para solo mensaje, sus árboles deben coincidir; para contenido, solo debe cambiar el patch previsto. Revisa lo preparado que queda pendiente y conserva la referencia de rescate hasta integrar con seguridad la sustitución revisada.

git show --stat HEAD
git diff rescue/before-amend HEAD
git status --short

Preguntas habituales

¿No-edit impide cambiar contenido? No, conserva el mensaje; el índice puede modificar el contenido. ¿Corrige commits anteriores? No directamente; requieren otro flujo de edición. ¿Después de push? Solo con una política explícita de historial compartido; una corrección adicional evita muchos problemas de coordinación.

Revisa la operación en FluxGit

Usa el historial visual y la vista de cambios de FluxGit para revisar la operación y los commits pertinentes. Conserva las comprobaciones de rama, historial compartido y archivos locales del ejemplo. La página de descarga muestra las versiones y plataformas disponibles.

Documentación oficial de Git

Flujos relacionados

Descargar FluxGit