> git undo, cancel, revert — conserva los cambios pase lo que pase con la palabra que escribas▋
Todas las consultas keep-changes de nuestro propio tablero de búsqueda — undo, cancel, revert — resueltas en una página: el comando por cada lío, la trampa de --hard y el reflog como red.
mrsaynothing· 11 de octubre de 2026· 7 min de lectura
git reset --soft HEAD~1Git trae cinco verbos para recuperar tu código — undo, cancel, revert, reset, restore — y ninguno se llama realmente undo. En algún lugar, un sinónimo está muy orgulloso de sí mismo.
Esto cuesta el diccionario. La semana pasada, la consulta cabecera de esta familia — git undo last commit keep changes — acumuló 73 impresiones en la posición 11.1 sin un solo clic, creciendo +100% semana contra semana, escoltada por cuatro primas escritas diferente. La gente no está confundida sobre git. Le tiene miedo a --hard, y cada tutorial genérico responde a ese miedo con el único flag que lo confirma. Esta página recorre la familia de arriba abajo: elige tu verbo, revisa la tabla, y solo entonces toca el historial.
| Verbo que la gente escribe | Lo que git realmente hace | ¿Conserva el trabajo? | El comando |
|---|---|---|---|
| "undo" | La etiqueta de rama retrocede un commit; los cambios vuelven en staging | Sí — en el index | git reset --soft HEAD~1 |
| "cancel" | Reset por defecto: la etiqueta retrocede, los cambios vuelven pero sin staging | Sí — en el working tree | git reset HEAD~1 |
| "revert" | Se añade un commit nuevo que deshace el viejo; el historial jamás se reescribe | Sí — como diff inverso | git revert HEAD |
| "unstage" | Las rutas salen del index; el contenido de los archivos queda intacto | Sí — nada salió del working tree | git restore --staged file.txt |
| "guárdalo por ahora" | El trabajo se empaca y se pone en un estante donde puedes retomarlo | Sí — en la pila de stash | git stash push -m "wip" |
La única decisión que importa
¿Cómo deshago mi último commit conservando los cambios?
git reset --soft HEAD~1 — la etiqueta de rama retrocede un commit y todo lo que hiciste vuelve en staging. Nada se borra, nada sale del index; puedes volver a commitear con un mejor mensaje o dividir el trabajo. El recorrido completo, incluido el caso con push, está en git undo last commit: keep changes, stay safe.
verify: después del reset, git status debe mostrar tus archivos en staging bajo «Changes to be committed» — ese es tu trabajo, de vuelta.
¿"git undo commit keep changes" significa algo distinto?
No — misma pregunta, misma respuesta. "Undo" nunca ha sido un comando de git; nuestro tablero muestra ambas variantes apuntando a problemas idénticos, y ambas se resuelven con reset --soft. Cuando la gente dice undo, quiere decir mueve la etiqueta, conserva el trabajo — lo único que un soft reset ha hecho en su vida.
¿Por qué "git revert last commit keep changes" tiene otra respuesta?
Porque revert es el único miembro de la familia que añade historial en vez de rebobinarlo. git revert HEAD crea un commit nuevo cuyo diff deshace el viejo — la parte de "conserva los cambios" es automática, porque el commit malo queda en el registro y el working tree termina sin él. Es la herramienta correcta en cuanto alguien más hizo pull; la bifurcación reset-vs-revert está trazada en git revert vs reset: which one saves your history?
Revert = deshacer público. Nunca reescribe lo que otros ya tienen; cancela el cambio con un commit nuevo y aditivo.
¿"git cancel commit" es un comando real?
No — cancel es lenguaje hablado, y la traducción de git al lenguaje hablado es reset. "Cancel commit but keep changes" y "cancel last commit but keep changes" — dos variantes más, la misma semana en nuestro tablero — caen ambas en git reset --soft HEAD~1. A git solo le importa la etiqueta que mueves y el flag que pasas; el vocabulario lo pones tú.
¿Puedo borrar un commit que nadie ha descargado?
Sí — un commit sin push sigue siendo tuyo y puedes remodelarlo sin consecuencias. reset --soft conserva el trabajo, reset HEAD~1 lo deja sin staging, y solo --hard lo tira a la basura — el único verbo sin conservación de esta página. Si el commit nunca fue tuyo y nada lo referencia, git gc es quien acaba recogiéndolo, no tú.
¿Se puede hacer stash de un solo archivo?
Sí — git stash push -m "wip" -- src/app.ts guarda una sola ruta y deja el resto de tu árbol tranquilo. El separador -- es lo que acota el stash a las rutas nombradas. Los casos borde del archivo único — incluido por qué el stash sobrevive a un checkout — viven en git stash a single file without losing the rest.
¿Se pueden cherry-pick varios commits?
Sí — un rango: git cherry-pick A^..B toma cada commit después de A hasta B incluido, en orden. Añade -n si los quieres en staging como un solo bulto en vez de commit por commit. El manual de conflictos para los rangos difíciles está en git cherry pick: multiple commits, branches, conflicts.
¿Cómo hago cherry-pick de varios commits de otra rama?
La misma forma de rango funciona entre ramas: git switch target && git cherry-pick A^..B. Git resuelve los commits desde la rama fuente y los reproduce en la tuya — espera conflictos donde las ramas divergieron, y tómalos de uno en uno en vez de en bloque.
¿Puedo recuperar un commit abandonado?
Casi siempre sí — el reflog recuerda por dónde anduvo HEAD durante unos 90 días por defecto (el gc.reflogExpire de git). Encuentra el hash abandonado con git reflog, luego git reset --soft HEAD@{1} para devolverlo bajo tu working tree. No estás deshaciendo nada — estás moviendo una etiqueta mientras git guarda silenciosamente los recibos.
¿Qué undo de git debería usar?
El de la tabla de arriba, honestamente — pero si quieres que la máquina elija: el generador git-undo recibe tu lío como entrada e imprime el comando exacto, y su post de lanzamiento muestra el razonamiento caso por caso. Cada recuperación probada de este racimo vive en el hub git-undo.
La trampa en la sala: --soft, --mixed, --hard
El flag decide dónde aterriza tu trabajo, y solo uno de los tres es peligroso. --soft lo devuelve en staging, --mixed (el predeterminado) sin staging, --hard iguala todo al commit objetivo y descarta el resto. Si ya escribiste --hard en pánico: el reflog todavía tiene el commit por ~90 días — git reflog, luego reset hacia el hash. El verbo que escribes en los primeros cinco segundos no decide nada para siempre; el diario de git dura más que tu arrepentimiento.
¿Qué variante te trajo hasta aquí — undo, cancel o revert? Dilo en los comentarios; el generador acepta las tres, y la más rara se vuelve el próximo post. El tablero dice que la mayoría escribió undo — el dato estaba antes que el consejo.
$ Entradas relacionadas · git undo
vLLM GGUF FAQ: Ten Search Questions, Answered
Ten real search questions about vLLM and GGUF — CPU support, serve syntax, quant coverage, the tokenizer trap — answered from the docs and our tested posts.
2026-10-09 · 6 min de lectura
git merge vs rebase — decide in 10 seconds
Merge or rebase, one question decides: did the commit leave your machine? The decision table, the fast-forward case, and the reflog fix when a rebase goes wrong.
2026-10-05 · 7 min de lectura
git stash a Single File Without Losing the Rest
Stash one file while the rest of your work stays put: git stash push -- <path>, then pop one file back out of any stash with git restore. Copy-paste commands.
2026-09-21 · 6 min de lectura
Git Revert vs Reset: Which One Saves Your History?
Git revert vs reset explained: which command undoes commits safely, when reset --hard destroys work, and how each rewrites shared GitHub history.
2026-09-15 · 7 min de lectura
