Cómo recuperar commits borrados con git reflog

Perder un commit puede generar un buen susto, sobre todo cuando has trabajado durante horas y piensas que el historial se ha quedado “limpio” para siempre. La buena noticia es que, en Git, borrar no siempre significa perder. Cuando un commit desaparece de la rama visible, todavía puede seguir accesible durante un tiempo gracias a git reflog.

Este comando es una especie de diario interno de referencias: registra a dónde han apuntado HEAD y las ramas locales en cada movimiento. Por eso, cuando te equivocas con un git reset, cambias de rama y parece que un commit se ha esfumado, reflog suele ser la herramienta que marca la diferencia. Si te interesa repasar primero cuándo conviene deshacer cambios sin riesgo, puedes echar un vistazo a Cómo deshacer cambios en Git sin perder tu trabajo.

Qué es git reflog y por qué salva commits

Git no solo guarda el historial de los commits; también registra los movimientos de las referencias locales. Cada vez que avanzas, retrocedes, haces checkout, ejecutas un reset o reescribes el historial, Git anota ese cambio en el reflog.

En la práctica, eso significa que puedes recuperar el puntero a un commit anterior aunque ya no aparezca en git log. Esta diferencia es importante: git log muestra el historial visible de una rama, mientras que git reflog enseña sus movimientos recientes, incluso los que ya no forman parte de la línea principal. Si quieres reforzar esta idea, también ayuda entender cómo ver el historial de cambios con git log.

Cuándo resulta útil

Hay varios escenarios típicos en los que reflog te puede rescatar:

• Has ejecutado git reset –hard y borraste commits que todavía necesitabas.
• Hiciste un checkout a otra rama y perdiste la referencia visual de tu trabajo.
• Reescribiste la historia con un rebase o un reset y quieres volver al punto anterior.
• Fusionaste cambios, pero después descubres que debías conservar una versión previa.

También es útil al trabajar con ramas locales. Si quieres revisar primero cómo se comportan las referencias en Git, conviene tener claro qué son las ramas y cómo avanzan, algo que tratamos en qué son las ramas en Git y cómo funcionan.

Cómo ver el reflog paso a paso

El comando básico es sencillo:

git reflog
# Muestra el historial reciente de movimientos de HEAD y referencias locales

La salida suele mostrar entradas como estas:

e3a1b2c HEAD@{0}: reset: moving to HEAD~1
f9d4a88 HEAD@{1}: commit: Corrige validación del formulario
7c2d901 HEAD@{2}: checkout: moving from main to feature/login

Cada línea te da una pista. El valor con formato HEAD@{n} representa una posición anterior de la referencia actual. El hash de commit que aparece al inicio es el que puedes usar para volver a ese estado.

Identificar el commit correcto

Si recuerdas aproximadamente cuándo hiciste la acción, revisa las últimas entradas de git reflog hasta encontrar el commit que quieres recuperar. Si no recuerdas el hash exacto, puedes apoyarte en la descripción del movimiento: commit, reset, checkout o merge.

Cuando localices el punto correcto, tienes dos caminos: moverte temporalmente a ese commit o crear una rama nueva para no perder tu estado actual. En entornos de trabajo reales, esta segunda opción suele ser la más prudente.

Recuperar un commit borrado sin riesgos

Supongamos que encuentras en el reflog el hash 7c2d901. Puedes inspeccionarlo así:

git checkout 7c2d901
# Te lleva a ese commit en modo detached HEAD

Esto sirve para comprobar que realmente era el punto que buscabas. Pero si quieres conservarlo de forma segura, lo ideal es crear una rama nueva:

git branch recuperacion-commit 7c2d901
# Crea una rama que apunta al commit recuperado

Después puedes cambiarte a ella con normalidad:

git switch recuperacion-commit
# Vuelves al estado rescatado y puedes seguir trabajando desde ahí

Si el objetivo era devolver tu rama principal a ese estado, también puedes mover la referencia con un reset, pero hazlo con cuidado. Si necesitas repasar las diferencias entre estrategias de deshacer cambios, te resultará útil cómo utilizar git reset correctamente y, cuando lo que quieres es crear una corrección inversa sin reescribir historia, cómo revertir un commit con git revert.

Ejemplo práctico de recuperación

Imagina que ejecutaste:

git reset --hard HEAD~1
# Se elimina el último commit de la rama visible

Después, revisas:

git reflog
# Localiza el hash del commit perdido antes del reset

Y finalmente recuperas el estado:

git branch rescate f9d4a88
git switch rescate
# El commit vuelve a estar accesible desde una rama

Este procedimiento es especialmente útil cuando el commit contenía cambios valiosos que todavía no habías enviado al remoto. Para entender mejor el flujo entre repositorio local y remoto, también conviene recordar cómo funciona git push y cuándo usar git pull o git fetch.

Qué hacer si el commit ya no aparece en reflog

El reflog no es eterno. Git conserva estas referencias durante un tiempo limitado y, con el mantenimiento del repositorio, entradas antiguas pueden desaparecer. Si el commit ya no está en el reflog local, la recuperación se complica, aunque todavía puede haber alternativas dependiendo de si el commit se llegó a compartir con otras personas o con un remoto.

En ese caso, conviene revisar si el commit fue subido a un servidor, si otro compañero lo tiene en su copia local o si existe alguna referencia en una rama remota. Aquí cobra valor tener bien organizados los repositorios y saber cómo gestionarlos, tal como se explica en cómo gestionar repositorios remotos con git remote y cómo conectar Git con GitHub paso a paso.

Buenas prácticas para no depender solo de la suerte

El reflog es potentísimo, pero no debería ser tu único plan de seguridad. Algunas prácticas ayudan a evitar sustos:

• Crea ramas temporales antes de hacer operaciones destructivas.
• Comprueba el estado con frecuencia usando git status.
• Usa commits pequeños y descriptivos para que sea más fácil localizar cambios.
• Evita reescribir historia en ramas compartidas sin coordinarte con el equipo.

Si quieres profundizar en higiene de trabajo con Git, también merece la pena consultar cómo consultar el estado del repositorio con git status y cómo añadir archivos al repositorio con git add, porque una buena disciplina diaria reduce mucho la probabilidad de tener que recuperar commits borrados.

Errores comunes al usar git reflog

El error más habitual es asumir que basta con mirar el hash y ejecutar cualquier comando sobre él sin comprobar el contexto. No todos los movimientos del reflog representan un commit útil para volver a una rama estable.

Otro fallo frecuente es usar git reset –hard justo después de encontrar el commit perdido, sin haber creado antes una rama de rescate. Si algo sale mal, habrás vuelto a mover la referencia y te tocará repetir el proceso. También es común confundir la recuperación de un commit con la restauración de archivos concretos; para eso, el enfoque cambia y puede ser mejor usar cómo recuperar archivos con git restore.

Conclusión

git reflog es una de esas herramientas que pasan desapercibidas hasta que realmente las necesitas. Cuando un commit parece perdido, ofrece una segunda oportunidad para encontrarlo, inspeccionarlo y restaurarlo con seguridad.

La clave está en entender que Git guarda más información de la que muestra a simple vista. Con una lectura correcta del reflog y una estrategia prudente —normalmente crear una rama antes de hacer cambios definitivos— puedes recuperar commits borrados sin convertir el incidente en una pérdida real de trabajo.

Fuentes y lecturas recomendadas

Documentación oficial de git reflog

Documentación oficial de git reset

GitHub Docs: trabajo con repositorios y referencias

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