Cómo utilizar git reset correctamente

Meta-descripción: Aprende a usar git reset correctamente, eligiendo entre soft, mixed y hard para deshacer commits sin perder control ni tu trabajo.

Dominar git reset marca un antes y un después en el manejo de Git. Es uno de esos comandos que parecen sencillos, pero que pueden cambiar por completo la historia de tu repositorio si no entiendes bien qué toca: el commit, el staging area o los archivos del directorio de trabajo.

Si ya has visto cómo crear commits, consultar el estado del proyecto o recuperar cambios con git restore, este artículo te ayudará a dar el siguiente paso: aprender cuándo reset es la herramienta correcta y cuándo conviene evitarla.

Qué hace realmente git reset

Git trabaja con tres “zonas” que conviene tener claras: el historial de commits, el índice o staging area y tu copia local de los archivos. git reset mueve una referencia de rama a otro commit y, según el modo que uses, también puede modificar el área de preparación o los archivos del directorio de trabajo.

La idea central es esta: git reset se usa para “retroceder” en el historial o deshacer cambios locales, pero no siempre de la misma manera. Por eso es importante conocer sus variantes antes de ejecutar cualquier comando.

Si todavía quieres repasar cómo se llega a ese historial, puedes volver a cómo ver el historial de cambios con git log o a git status, que te ayudan a interpretar el punto en el que estás antes de actuar.

Los tres modos de git reset

git reset –soft

El modo –soft mueve la referencia de la rama al commit indicado, pero conserva intactos tanto el staging area como los cambios del directorio de trabajo. En la práctica, sirve para “deshacer” un commit sin perder lo que habías preparado.

Es muy útil cuando has hecho un commit demasiado pronto o quieres reescribirlo con un mensaje más claro, añadir archivos que se te olvidaron o dividir el cambio en varios commits más pequeños.

# Mueve la rama al commit anterior, pero mantiene los cambios preparados
git reset --soft HEAD~1

# Ahora puedes rehacer el commit con más contenido o con otro mensaje
git commit -m "Mensaje corregido y cambio ampliado"

git reset –mixed

Es el comportamiento por defecto de git reset. Mueve la rama al commit elegido y saca los cambios del staging area, pero deja los archivos modificados en tu directorio de trabajo. Dicho de otra forma: conservas el trabajo, pero Git deja de considerarlo preparado para el próximo commit.

Este modo es ideal cuando quieres revisar qué has preparado antes de confirmar, o cuando necesitas reorganizar un commit en partes más pequeñas. Si quieres volver a hacer staging de forma más selectiva, puede ser buena idea releer cómo añadir archivos al repositorio con git add.

# Equivale a git reset --mixed HEAD~1
git reset HEAD~1

# Los archivos siguen modificados, pero ya no están en staging
git status

git reset –hard

El modo –hard es el más agresivo. Además de mover la rama, elimina los cambios del staging area y también sobrescribe el directorio de trabajo para que coincida exactamente con el commit elegido. Es decir: lo que no estuviera guardado en otro sitio, se pierde.

Por eso, este modo solo debería usarse cuando tienes claro que no necesitas esos cambios o cuando ya los respaldaste de otra manera. En escenarios de limpieza total puede ser útil, pero conviene pensar dos veces antes de ejecutarlo.

# Peligroso: descarta cambios locales no commiteados
git reset --hard HEAD~1

Cuándo usar git reset y cuándo no

git reset es una herramienta excelente para repositorios locales y para revisar tu trabajo antes de compartirlo. Si aún no has hecho push, puedes reorganizar commits, limpiar el historial local o corregir errores de flujo con bastante libertad.

Sin embargo, en ramas compartidas o ya publicadas, reset exige mucha más cautela. Reescribir historial que otros ya han descargado puede generar conflictos y confusión en el equipo. En esos casos, suele ser mejor optar por estrategias más conservadoras, como hacer un commit de revertido o coordinar muy bien el cambio.

Aquí conviene recordar la diferencia con cómo deshacer cambios en Git sin perder tu trabajo: no todas las formas de “deshacer” implican borrar historial. Elegir bien evita pérdidas accidentales.

Diferencia entre reset, restore y revert

Muchos usuarios mezclan estos comandos porque todos sirven para deshacer algo, pero su alcance es distinto. git restore trabaja sobre archivos concretos y es más específico para recuperar o descartar cambios en el árbol de trabajo o en staging. Por su parte, git revert crea un nuevo commit que invierte otro anterior, sin reescribir el historial.

git reset, en cambio, cambia la posición de la rama y puede modificar varias capas a la vez. Esa potencia lo hace especialmente útil para ajustar commits locales, pero también más sensible que otras opciones.

Si vienes de aprender git restore, puedes pensar en esta regla rápida: restore actúa sobre archivos; reset actúa sobre commits y estado; revert conserva el historial creando una inversión nueva.

Casos prácticos habituales

Corregir el último commit

Si acabas de confirmar cambios y notas que falta un fichero o el mensaje no es claro, git reset –soft HEAD~1 puede devolverte al estado previo al commit manteniendo el trabajo listo para volver a confirmar.

Deshacer staging sin tocar archivos

Cuando has preparado demasiados archivos o quieres reorganizar el próximo commit, un git reset sin argumentos puede ayudarte a salir del área de preparación sin perder las modificaciones locales.

Volver a un estado limpio

Si estás en un experimento local y quieres dejar el repositorio exactamente como estaba en un commit anterior, el modo –hard lo hace rápido. Aun así, antes de usarlo, asegúrate de que no necesitas recuperar nada o de que ya lo has respaldado con otro commit o branch.

Buenas prácticas para usar git reset sin riesgo

La primera buena práctica es simple: revisa siempre el estado del repositorio antes de actuar. git status te dará una foto clara de lo que está preparado y de lo que sigue modificado.

La segunda es no usar –hard por costumbre. Si tu objetivo es solo corregir un commit, normalmente –soft o –mixed son opciones más seguras. La tercera consiste en comprobar si esa rama está compartida; si lo está, piensa en el impacto para el resto del equipo.

Y si tu duda es más amplia sobre cuándo conviene rehacer historial o simplemente revertirlo, merece la pena volver al artículo de deshacer cambios en Git sin perder tu trabajo, porque ahí está la diferencia entre trabajar con precisión y perder información útil.

Resumen rápido de comandos

# Deshacer el último commit manteniendo cambios en staging
git reset --soft HEAD~1

# Quitar el último commit del historial y dejar los cambios en archivos
git reset --mixed HEAD~1

# Eliminar commit, staging y cambios locales
git reset --hard HEAD~1

# Ver en qué punto estás antes de tocar el historial
git status
git log --oneline

En resumen, git reset no es un comando peligroso por sí mismo; lo peligroso es usarlo sin entender qué parte del repositorio va a modificar. Si adoptas el hábito de identificar primero tu objetivo —revisar, deshacer, limpiar o reescribir—, elegir el modo correcto será mucho más fácil.

Con práctica, git reset se convierte en una herramienta muy precisa para mantener tu historial local ordenado, corregir errores de forma rápida y trabajar con más confianza.

Fuentes y lecturas recomendadas

Documentación oficial de git reset

Git Book: Reset Demystified

Documentación oficial de GitHub

Xose de la Paz

Más de 20 años transformando pasión en profesión. Experto en desarrollo Full Stack con una visión integral que abarca desde la gestión de servidores y redes hasta el diseño de interfaz. Soy un "todoterreno" tecnológico que cree en el aprendizaje continuo y la visión global de los proyectos. Entre despliegue y despliegue, me pierdo por el mundo con mi cámara al hombro.

Web | LinkedIn