Git revert, reset y restore: qué usar para deshacer cambios sin perder trabajo
Publicado el 2026-10-26 por frfrand
Elegir entre revertir un commit, mover HEAD o recuperar un archivo
Tres comandos para «deshacer» que no hacen lo mismo. Elegir mal puede borrar cambios locales o reescribir una rama que otras personas ya usan. Conviene conocer la diferencia antes de copiar una orden con --hard.
La idea es usarlo para resolver un problema de verdad, no memorizar comandos porque quedan bien en una captura. Vamos con lo esencial, un ejemplo de trabajo y los errores que más conviene evitar.
Qué hace Git revert, reset y restore y cuándo sirve
git revert crea un commit que invierte el efecto de otro: es apropiado para cambios ya compartidos. git reset mueve la referencia de la rama y puede alterar índice y archivos; --hard descarta trabajo no confirmado. git restore recupera archivos del índice o una revisión según opciones.
Si estás aprendiendo, probalo primero en un repositorio o entorno de prueba. Si administrás producción, documentá el estado antes de ejecutar nada que altere archivos, historial o datos. Eso te permite entender qué cambió y recuperarte si te equivocás.
Ejemplo para copiar y entender
# Deshacer un commit publicado sin reescribir historial
git revert abc1234
# Ver el estado antes de tocar archivos
git status
git diff
# Recuperar UN archivo modificado localmente
git restore -- ruta/al/archivo.py
# Mover HEAD conservando cambios en staging
git reset --soft HEAD~1No copies la orden final sin mirar el estado previo. Los nombres de ramas, host, usuario o rutas son ejemplos; reemplazalos por los de tu proyecto. Algunos comandos modifican archivos o hacen peticiones que pueden escribir datos.
Cómo lo usaría paso a paso
- Paso 1. Si el commit ya está en una rama compartida, preferí
reverty revisá los posibles conflictos. - Paso 2. Para un archivo local que querés descartar, inspeccioná primero
git diff. - Paso 3. Para corregir un commit aún no publicado, evaluá
reset --softo--mixedsegún quieras conservar staging. - Paso 4. Evitá
reset --hardsi no estás absolutamente seguro de que esos cambios pueden perderse. - Paso 5. Antes de desplegar la reversión, ejecutá las pruebas y comprobá las migraciones de base.
Detenete después de cada paso y comprobá el resultado. Si algo falla, anotá el mensaje exacto antes de cambiar de estrategia. Saltar entre cinco soluciones aleatorias suele dificultar encontrar la causa real.
Un caso que podría pasarte trabajando con clientes
Se publica un cambio de precio incorrecto en una web. En main compartida conviene crear un revert trazable, no empujar un reset forzado que mueva el historial de todos.
El objetivo no es que «funcione una vez», sino que puedas explicar cómo lo repetís sin comprometer otra aplicación. Si hay datos o credenciales de clientes, trabajá con pruebas separadas y accesos mínimos.
El error que más veo
Revertir código no revierte una migración de PostgreSQL ni una operación de datos. Si el despliegue modificó el esquema, necesitás un plan específico para compatibilidad y recuperación.
Una regla sencilla: si no puedes explicar qué hará el comando sobre tu código o servidor, mira primero su ayuda oficial. Así evitarás confundir una solución rápida con un problema nuevo.
¿Dónde entra ArduMaker?
Con el despliegue Git de ArduMaker, conservar el hash de cada versión permite asociar un error a un commit. Pero la reversión de base y archivos persistentes debe diseñarse aparte.
Por ejemplo, puedes desplegar desde un repositorio Git a un VPS, asociar un dominio HTTPS y administrar servicios y bases desde el mismo entorno. El panel reduce tareas repetitivas de infraestructura, pero no reemplaza Git, las pruebas ni la revisión de permisos del proyecto.
Preguntas rápidas antes de aplicarlo
¿Esto cambia producción? Depende de dónde ejecutes la acción. Prueba localmente primero, identifica el commit o servicio afectado y prepara un plan de recuperación.
¿Cómo compruebo que salió bien? No te quedes con la ausencia de mensajes de error: revisa el estado, ejecuta un test funcional y comprueba los logs o el historial correspondiente.
¿Conviene automatizarlo? Si es repetible y tiene resultados verificables, sí. Pero la automatización debería fallar de forma clara y no esconder errores o credenciales.
Para ampliar
Resumen: la herramienta útil no es la que tiene más opciones, sino la que te permite entender qué cambió, comprobarlo y seguir trabajando sin sorpresas.