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 🙌.

Secuencia segura
git status
git branch backup/antes-de-deshacer
git restore src/app.js

🧪 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 😉.

Esta la hice en febrero de 2026 para facilitar el aprendizaje de mis alumnxs. Aprender desarrollo web practicando. La idea es que crezca semanalmente con nuevos temas, tests y retos.

Inspirado en MDN, en W3Schools, en Codepen, en el crack de Manz y en mil sitios de documentación sobre desarrollo web. Quería aportar además de bloques teóricos con ejemplos, la gamificación de los retos y el sistema de test que ya tenía en culTest .

Si te gustó, si no te gustó, si quieres saludarme, o invitarme a 🍻 no dudes en escribirme en cristianeslava@gmail.com .