Cuando empiezas con control de versiones, Git Reset y Git Revert se convierten en tus mejores aliados para deshacer commits sin romper el repositorio. Ambos comandos te ayudan a corregir errores, limpiar el historial y resolver conflictos, pero funcionan de maneras muy distintas y conocer la diferencia te puede ahorrar horas de trabajo perdido.

¿Cuál es la diferencia entre Git Reset y Git Revert?

La distinción es clave antes de tocar tu repositorio. Cada comando responde a una intención diferente, aunque ambos parezcan hacer lo mismo a primera vista.

Git Reset mueve el puntero de tus commits a uno anterior. Esto te permite regresar en el tiempo, explorar el historial e incluso recordar qué hiciste en cada paso. Útil si tienes mala memoria y quieres revisar versiones previas sin perder el rumbo [00:43].

Git Revert, en cambio, es más quirúrgico. Crea un nuevo commit que actúa como tapón y deshace los cambios de un commit específico, sin borrar nada del historial [01:36].

¿Qué hace Git Revert? Crea un nuevo commit que revierte los cambios de uno anterior. El historial se mantiene intacto y puedes ver tanto el commit original como el revert.

¿Cómo uso Git Revert para deshacer un commit?

Imagina que subiste un archivo llamado error.txt que no debería estar en el repositorio. Alguien de tu equipo te avisa y necesitas revertir ese cambio sin afectar el resto del historial.

El flujo es directo:

1. Ejecuta git log para ver tu historial de commits.
2. Identifica el hash del commit que quieres revertir, ese identificador único frente a cada mensaje.
3. Copia el hash y ejecuta git revert <hash>.
4. Se abre un editor con un mensaje predefinido tipo "Revert nuevo archivo especial creado". Agrega tu firma o nota por camaradería con el equipo.
5. Guarda y listo, tu repositorio vuelve al estado anterior [03:50].

Al correr git log después, verás que revert no elimina el commit original, simplemente añade uno nuevo que neutraliza esos cambios. Si haces ls, el archivo problemático ya no aparece, pero el rastro queda documentado [04:43].

¿Por qué importa el mensaje del commit?

Un buen mensaje hace que tu historial sea legible. Cuando uses git revert, el commit generado describe qué se está deshaciendo y quién lo hizo. Eso facilita auditar decisiones más adelante [03:30].

¿Cómo funciona Git Reset y sus parámetros?

Git Reset es más agresivo. En lugar de crear un commit nuevo, mueve el puntero HEAD a un commit previo y, según el parámetro que uses, también puede borrar archivos y commits posteriores.

Tienes tres modos disponibles:

• soft: elimina los archivos pero mantiene los cambios en staging.
• mixed: regresa los commits y deja los cambios sin agregar.
• hard: deshace todos los cambios, archivos y commits posteriores al hash indicado [06:46].

El flujo práctico se ve así: creas un archivo reset.txt, lo agregas con git add, haces commit con un mensaje claro como "nuevo archivo para reiniciar", y luego decides que quieres volver varios commits atrás. Copias el hash del commit destino y ejecutas:

bash git reset --hard <hash>

Al correr git log después, HEAD y main aparecen ubicados justo donde querías regresar [07:11].

¿Cuándo debo usar git reset hard? Solo como último recurso. Borra archivos, commits y puede afectar el trabajo de tu equipo si el repositorio es compartido.

¿Qué es el HEAD en Git y por qué importa?

Cuando ejecutas git log, ves un paréntesis con la palabra HEAD apuntando a main. Ese puntero indica cuál es el último commit realizado y dónde estás parado en la línea de tiempo del proyecto. Cada vez que haces un nuevo commit, HEAD se mueve automáticamente a esa nueva posición [02:18].

Tanto git reset como git revert manipulan ese puntero, por eso entender HEAD es la base para no perderte al deshacer cambios.

¿En qué casos conviene usar cada comando?

Ambos comandos brillan en tres escenarios concretos:

• Corrección de errores: si subiste un archivo que no funciona, git revert es la opción limpia. Si varios compañeros también quieren revertir, evalúa git reset con cuidado.
• Limpieza del historial: cuando el log es demasiado largo y el proyecto ya está sólido, puedes consolidar versiones para navegar más fácil con git log.
• Manejo de conflictos entre ramas: aunque casi siempre los conflictos se resuelven sin reset, en casos extremos puede ser una salida [08:36].

La recomendación práctica: comunica siempre con tu equipo antes de usar reset, sobre todo con el parámetro hard. Reset y revert no son intercambiables, y elegir mal puede borrar trabajo ajeno.

¿Te ha pasado tener que deshacer un commit en un momento crítico? Cuéntame en los comentarios qué comando usaste y cómo te fue.