Git Reset vs Git Revert: El Duelo de los Deshaceres

Dos comandos que me han salvado el pellejo más veces de las que me gustaría admitir.

Cuando empecé a trabajar con Git, cometer errores era parte del menú diario. Crear archivos innecesarios, cometer antes de tiempo, romper el código y… bueno, tú sabes. En ese proceso, dos comandos se convirtieron en mis salvavidas: git reset y git revert. Son diferentes, tienen objetivos distintos y, si los entiendes bien, pueden evitarte más de un dolor de cabeza.

Entendiendo git reset

git reset es como una máquina del tiempo: te lleva a un punto anterior en la historia del proyecto, pero con poder para borrar el pasado si así lo decides.

¿Qué hace?

• Mueve el puntero HEAD a un commit anterior.
• Puede modificar tanto el historial como los archivos del working directory.
• Es ideal para deshacer errores locales antes de compartir tu trabajo.

Tipos de reset:

git reset --soft <hash>   # Mantiene los archivos como están, pero cambia el historial
git reset --mixed <hash>  # Borra el área de staging, mantiene los archivos
git reset --hard <hash>   # Borra todo: staging, archivos y commits posteriores

⚠️ Nota: Cada vez que haces un commit, Git genera un identificador único, llamado hash. Es una cadena larga de letras y números (como 3f4d2c1...)

Cuándo usarlo:

• Antes de hacer push si quieres reorganizar commits.
• Para deshacer rápidamente cambios no deseados en tu propio entorno.

⚠️ Cuidado: git reset --hard es como un botón de autodestrucción. No hay marcha atrás (a menos que seas un ninja con git reflog).

Entendiendo git revert

Si reset borra el pasado, revert lo respeta. Este comando no elimina commits, sino que crea uno nuevo que revierte los cambios de un commit anterior.

¿Qué hace?

• Genera un nuevo commit que “deshace” otro anterior.
• Ideal para mantener un historial limpio y colaborativo.

Ejemplo:

git revert <hash>

Esto abrirá un editor de texto donde puedes explicar por qué estás revirtiendo. Sé humano: “Este commit causaba un bug en producción. Revertido hasta nuevo aviso.”

Cuándo usarlo:

• En ramas compartidas (¡por favor no uses reset --hard en main!).
• Para deshacer errores específicos sin reescribir el historial.

Demostración práctica

1. Creas un archivo con errores:

touch error.txt
git add error.txt
git commit -m "Archivo con error"

2. Lo revientes con git revert:

git log  # obtén el hash del commit
git revert <hash>

3. Git genera un nuevo commit que revierte el anterior. Todo bien, todo legal.
4. Ahora haces otra prueba:

touch reset.txt
git add .
git commit -m "Archivo de prueba para reset"

5. Usas git reset --hard para viajar en el tiempo:

git log  # elige un hash anterior
git reset --hard <hash>

🎯 Resultado: regresaste el proyecto al estado exacto de ese commit. Pero ojo, los cambios intermedios se perdieron (salvo que los tengas en backup o en reflog).

Buenas prácticas

• Usa mensajes de commit descriptivos, te salvarán en momentos críticos.
• Piensa dos veces antes de usar reset --hard, especialmente en ramas compartidas.
• Usa revert para deshacer con responsabilidad, sin pisotear el historial de tus compañeros.
• Explora git reflog, ese comando es tu última esperanza si algo sale mal.

Conclusión: ¿Reset o Revert?

Depende de lo que quieras lograr:

Reflexión final

A veces olvidamos que Git no solo es una herramienta técnica, también es una herramienta para pensar. Entender cómo y cuándo deshacer algo no es solo cuestión de comandos, es una cuestión de responsabilidad.

Si estás aprendiendo Git, no te obsesiones con tenerlo todo perfecto. Aprende a equivocarte y a revertir con clase.