Deshacer cambios sin liarla: restore, reset y revert

Aprende a corregir errores con comandos seguros y entiende cuándo conviene cada uno para no romper el historial compartido.

En Git casi todo tiene arreglo, pero no todo se arregla igual. La clave está en saber si el cambio está local, en staging o ya compartido.

<code>restore</code> suele ser la opción segura para volver atrás en archivos; <code>revert</code> crea un nuevo commit inverso y es ideal cuando el cambio ya está en remoto.

Si aún no dominas commits limpios, vuelve un momento a <a href="/curso/git-github/leccion/git-github-flujo-add-commit-log-fundamentos">el flujo add/commit/log</a>; te hará esta lección mucho más sencilla.

  • Antes de deshacer, pregúntate dónde está el cambio.
  • Si no has hecho commit, normalmente usarás <code>git restore</code> (archivo) o <code>git restore --staged</code> (sacarlo de staging). Si ya hiciste commit pero no lo compartiste, puedes reorganizar localmente.
  • Si el commit ya está en remoto y otros dependen de él, evita reescribir historia: usa <code>git revert</code> para mantener trazabilidad limpia.
  • Local sin commit: <code>restore</code>
  • En staging: <code>restore --staged</code>

Mapa rápido de decisión

Antes de deshacer, pregúntate dónde está el cambio.

Si no has hecho commit, normalmente usarás <code>git restore</code> (archivo) o <code>git restore --staged</code> (sacarlo de staging). Si ya hiciste commit pero no lo compartiste, puedes reorganizar localmente.

Si el commit ya está en remoto y otros dependen de él, evita reescribir historia: usa <code>git revert</code> para mantener trazabilidad limpia.

  • Local sin commit: <code>restore</code>
  • En staging: <code>restore --staged</code>
  • Compartido en remoto: <code>revert</code>
  • Historial local privado: <code>reset</code> con criterio

Seguridad mental antes de tocar historial

Haz una foto de estado y luego actúa.

Antes de ejecutar comandos destructivos, mira <code>git status</code> y, si dudas, crea una rama temporal de respaldo. Ese hábito evita sustos cuando vas con prisa.

En equipos, documenta en la PR por qué revertiste o rehiciste un cambio. No es burocracia: es comunicación profesional 🙌.

Git & GitHub
04

Deshacer cambios sin liarla: restore, reset y revert

Aprende a corregir errores con comandos seguros y entiende cuándo conviene cada uno para no romper el historial compartido.

Código del tema: Comandos reproducibles y trazables

📘 Teoría

Mapa rápido de decisión

Antes de deshacer, pregúntate dónde está el cambio.

Si no has hecho commit, normalmente usarás git restore (archivo) o git restore --staged (sacarlo de staging). Si ya hiciste commit pero no lo compartiste, puedes reorganizar localmente.

Si el commit ya está en remoto y otros dependen de él, evita reescribir historia: usa git revert para mantener trazabilidad limpia.

  • Local sin commit: restore
  • En staging: restore --staged
  • Compartido en remoto: revert
  • Historial local privado: reset con criterio

Seguridad mental antes de tocar historial

Haz una foto de estado y luego actúa.

1

Antes de ejecutar comandos destructivos, mira git status y, si dudas, crea una rama temporal de respaldo. Ese hábito evita sustos cuando vas con prisa.

2

En equipos, documenta en la PR por qué revertiste o rehiciste un cambio. No es burocracia: es comunicación profesional 🙌.

🧪 Aprende probando

Ejemplo Ejemplo guiado: descartar cambios de un archivo Vuelve un archivo al último commit sin tocar el resto.
Ejemplo Ejemplo guiado: revertir un commit compartido Crea un commit inverso en vez de reescribir historial remoto.
Ejemplo Demo: checklist antes de deshacer Estado, respaldo y acción: orden profesional.

🏁 Retos

Reto Reto: sacar archivo de staging Quita un archivo de staged sin perder cambios locales.
Reto Reto: revertir último commit Genera commit inverso del commit más reciente.

🧰 Recursos

Test

Comprueba tus conocimientos con un test sobre Git & GitHub.

Test de Git & GitHub

¿Qué es esto?

Soy Cristian Eslava y a veces hago webs para procrastinar yo y vosotros. culTest

La hice en febrero de 2026 para facilitar el aprendizaje de mis alumnos. La idea es aprender desarrollo web practicando y que el proyecto siga creciendo con nuevos temas, tests y retos.

Está inspirada en MDN, W3Schools, CodePen, Manz y muchos otros sitios de documentación sobre desarrollo web. Quería combinar teoría útil, ejemplos ejecutables, retos y el sistema de tests que ya tenía en culTest. culTest

Si te gustó, si no te gustó o si quieres escribirme, puedes hacerlo en cristianeslava@gmail.com