Si el commit ya se envió a una rama compartida y otras personas pueden haber basado trabajo en él, la opción generalmente más segura es git revert. El comando no borra el commit anterior: crea un nuevo commit que aplica el inverso de sus cambios. git reset, en cambio, mueve HEAD y, según el modo, también puede modificar el índice y el árbol de trabajo. Esto es útil para corregir un historial local, pero puede provocar pérdida de trabajo ajeno cuando se reescribe un historial ya publicado.
Regla práctica: un historial compartido pide revert
Empieza por una pregunta: ¿el commit que quieres deshacer ya llegó al remoto y otra persona pudo verlo, descargarlo o basar trabajo en él? Si la respuesta es sí, conviene preservar el historial. git revert <commit> crea un nuevo commit que neutraliza los cambios introducidos por el commit elegido sin mover hacia atrás el puntero de la rama.
Esto es especialmente importante en ramas como main, master, develop o cualquier rama de equipo. Quienes ya tienen el commit original conservan un historial compatible con el remoto. El nuevo commit de reversión aparece después y deja registrado qué ocurrió y cuándo se tomó la decisión.
Cuándo tiene sentido git reset
git reset es apropiado cuando controlas el historial que estás modificando, sobre todo antes de publicar los commits. En la forma que recibe un commit como destino, el comando mueve el HEAD de la rama actual hasta ese punto. El efecto sobre el índice y los archivos depende del modo elegido.
| Comando | HEAD | Índice | Archivos de trabajo | Uso típico |
|---|---|---|---|---|
| git reset --soft HEAD~1 | Retrocede un commit | Se conserva | Se conservan | Rehacer el último commit manteniendo todo preparado para commit |
| git reset --mixed HEAD~1 | Retrocede un commit | Se restablece | Se conservan | Deshacer el commit y mantener los cambios de archivos fuera del stage |
| git reset --hard HEAD~1 | Retrocede un commit | Se restablece | Se restablecen | Descartar el commit y los cambios rastreados correspondientes, solo cuando eso sea realmente lo deseado |
Sin indicar un modo, git reset usa el comportamiento de --mixed. El caso crítico es --hard: restablece el índice y el árbol de trabajo al destino y descarta cambios en archivos rastreados que no existan en ese estado. Por eso no debe tratarse como un botón genérico de deshacer.
Ejemplo seguro para un commit ya publicado
Supongamos que el commit problemático es a1b2c3d y ya está en una rama compartida. Un flujo predecible consiste en actualizar tu vista del remoto, confirmar el commit y crear la reversión:
git fetch origin git log --oneline --decorate -n 10 git revert a1b2c3d git push origin nombre-de-ramaSi la reversión genera conflictos, Git detiene la operación para que puedas resolverlos. Después de editar los archivos y marcar las resoluciones con git add, continúa con git revert --continue. Si descubres que elegiste el commit equivocado o no quieres seguir, usa git revert --abort para abandonar la reversión en curso.
Ejemplo para corregir el último commit mientras sigue siendo local
Si el commit todavía no se publicó y solo quieres rehacerlo sin perder los cambios, --soft suele ser la alternativa más conservadora:
git reset --soft HEAD~1 git status # ajusta archivos o mensaje según sea necesario git commitLos cambios permanecen preparados en el índice. Si prefieres que vuelvan al árbol de trabajo sin quedar en el stage, usa git reset HEAD~1, equivalente a --mixed en este contexto.
Por qué reset después del push puede afectar a otras personas
Después de que un reset mueve una rama hacia atrás, tu historial local deja de contener, en esa línea de la rama, commits que todavía pueden existir en el remoto y en los clones de compañeros. Un push normal suele ser rechazado porque no es una actualización fast-forward. Forzar la actualización sustituye la referencia remota y puede hacer que commits de otras personas dejen de ser accesibles desde la rama compartida.
La documentación de git push advierte que --force puede hacer que el repositorio remoto pierda commits. --force-with-lease añade una protección: la actualización forzada falla si la referencia remota no está en el valor esperado. Aun así, no convierte la reescritura de un historial compartido en una operación rutinaria y la documentación señala precauciones cuando herramientas ejecutan fetch en segundo plano.
Si la reescritura es inevitable
Algunos equipos permiten rebase, squash u otras reescrituras en ramas de feature. En esos casos, la seguridad depende de las reglas del equipo y de saber exactamente quién puede estar usando la rama. Antes de un push forzado, actualiza las referencias remotas, confirma el destino y evita un --force a ciegas. Cuando la política permite reescritura, --force-with-lease ofrece mejor protección que --force, pero no sustituye la coordinación.
Cómo recuperar un reset local hecho por error
Un reset que movió HEAD no siempre significa que el commit sea inmediatamente irrecuperable. El reflog local registra movimientos de referencias y puede ayudarte a encontrar el identificador anterior:
git reflog git show <hash-encontrado>Después de identificar el commit correcto, puedes crear una rama temporal para preservarlo antes de hacer cualquier otra modificación:
git branch recuperacion <hash-encontrado>El reflog es local. Registra movimientos de referencias en ese repositorio específico, así que no debe tratarse como sustituto de copias de seguridad, revisión de comandos o protección del historial remoto.
¿Y si el commit que hay que deshacer es un merge?
Revertir un merge exige indicar qué padre debe considerarse la línea principal con -m <parent-number>. No conviene elegir ese número por prueba y error. Primero inspecciona el merge e identifica correctamente la línea principal. Además, revertir un merge registra que no se desean los cambios incorporados por ese merge, lo que puede influir en merges posteriores. Revisa el grafo y la intención antes de ejecutar el comando.
Checklist antes de deshacer un commit
- Confirma en qué rama estás con git status o git branch --show-current.
- Actualiza las referencias remotas con git fetch antes de decidir sobre un historial publicado.
- Verifica el hash y el contenido del commit con git show <hash>.
- Si el commit ya fue compartido, prefiere git revert.
- Si el commit es solo local, elige entre reset --soft, reset --mixed y reset --hard según lo que deba ocurrir con el índice y los archivos.
- Evita reset --hard cuando todavía necesites conservar cambios locales.
- No hagas push forzado en una rama compartida sin una política y coordinación explícitas.
En resumen
git revert y git reset deshacen problemas de maneras diferentes. revert agrega un nuevo commit inverso y es la elección predeterminada cuando el historial ya está compartido. reset reposiciona el historial local y es más apropiado antes de publicar, cuando controlas los commits afectados. Para no borrar el trabajo de otras personas, la decisión debe partir del estado del historial y no solo del resultado que quieres ver en los archivos.
