Saltar al contenido
Todas las publicaciones

P7

Deshacer errores en Git

Cinco comandos para deshacer casi cualquier error en Git (restore, amend, revert, reset y reflog) y cuándo conviene usar cada uno.

Casi todo tiene vuelta atrás

Git guarda mucho más de lo que parece, así que casi cualquier error se puede deshacer. Lo difícil es elegir el comando correcto, y eso depende de una sola pregunta: ¿en qué punto estás? ¿El cambio aún no tiene commit, el commit sigue en tu máquina o ya lo subiste?

Los hashes que aparecen en las imágenes son de ejemplo.

1. Cambios sin commit: git restore

Si editaste un archivo y quieres dejarlo como estaba en el último commit, git restore <archivo> descarta esos cambios. Si solo lo agregaste al stage por error, git restore --staged <archivo> lo saca del stage sin tocar lo que escribiste.

2. El último commit salió mal: git commit --amend

¿Mensaje con errores o un archivo olvidado? Agrega lo que falte y ejecuta git commit --amend: el último commit se rehace. Ojo: el resultado es un commit nuevo, con otro hash. Úsalo solo si todavía no hiciste push.

3. El commit ya está subido: git revert

Cuando otras personas ya pueden tener ese commit, no conviene reescribir la historia. git revert <hash> crea un commit nuevo que deshace los cambios del anterior. La historia queda intacta y nadie del equipo pierde nada.

Fotograma del video: git revert añade un commit que deshace el anterior sin reescribir la historia (hashes de ejemplo)

4. Volver atrás en local: git reset

git reset mueve HEAD (y tu rama) a un commit anterior. Lo que cambia entre sus modos es dónde quedan los cambios del commit que quitas:

  • git reset --soft HEAD~1: los cambios quedan en el stage, listos para un nuevo commit.
  • git reset --mixed HEAD~1 (el modo por defecto): los cambios quedan en tus archivos, fuera del stage.
  • git reset --hard HEAD~1: los cambios se borran del directorio de trabajo. Es el único de los tres que puede hacerte perder trabajo.
Fotograma del video: los tres modos de git reset y el aviso de --hard (hashes de ejemplo)

5. El salvavidas: git reflog

¿Hiciste un reset y desapareció un commit? Normalmente no se perdió. git reflog muestra por dónde pasó HEAD en tu repositorio, con el hash de cada paso. Con ese hash vuelves a él con git reset --hard <hash> o lo rescatas en una rama nueva con git branch rescate <hash>.

Dos límites que conviene conocer: el reflog es local (no viaja con el push) y solo recupera lo que llegó a tener commit. Lo que nunca se commiteó y borraste con --hard no vuelve.

Fotograma del video: git reflog encuentra el commit y vuelve a apuntar HEAD a él (hashes de ejemplo)

La regla de oro

En ramas compartidas, revert: no reescribe nada de lo que otros ya tienen. En local, reset: todavía nadie depende de esa historia. Y si algo sale mal, antes de entrar en pánico, git reflog.

¿Y tú?

¿Cuál de estos comandos te salvó la vida alguna vez?

  • #Git
  • #DevOps
  • #Programacion
  • #SoftwareEngineering
  • #DesarrolloDeSoftware

¿Necesitas algo parecido en tu equipo o tu producto?

Cuéntame el contexto y te respondo en menos de 24 horas. Si prefieres revisar la trayectoria antes, el CV está a un clic.