Llevamos seis módulos aplazando esta lección. En la 03-02 dijimos que el reflog explica cómo Git recuerda por dónde ha pasado HEAD. En la 03-06 prometimos que borrar una rama con -D casi nunca es irreversible, y remitimos aquí. En la 05-01 dijimos que un rebase desastroso se puede deshacer, y remitimos aquí. En la 05-04, que un stash drop accidental es recuperable. En la 09-02, que los commits que un reset --hard deja atrás siguen ahí. Y en la 09-03, que origin/main@{1} guarda dónde estaba el servidor antes de la reescritura.

Todas esas promesas se apoyan en la misma pieza, y es hora de desarrollarla entera.

El reflog es probablemente la funcionalidad de Git con mejor relación entre lo que salva y lo poco que se conoce. Mucha gente lleva años usando Git sin haberlo ejecutado nunca, y es exactamente el comando que convierte "he perdido tres días de trabajo" en "he tardado dos minutos en recuperarlo".

Empecemos por lo más importante: si has llegado aquí en pánico, no has perdido nada, siempre que lo que buscas llegara a ser un commit. Sigue leyendo con calma.

1. Qué es el reflog y dónde vive
2. Local y temporal: los dos límites que hay que conocer
3. Leer git reflog
4. HEAD@{n} frente a HEAD@{tiempo}
5. El patrón universal de recuperación
6. Recetario: reset --hard, rama borrada, rebase, merge, --amend
7. Cuando el reflog no basta: git fsck --lost-found
8. Recuperar un stash eliminado
9. Los límites reales: lo que no se puede recuperar
10. Higiene: no destruir tu propia red de seguridad

El reflog es el registro local de todos los movimientos de cada referencia.

Cada vez que una referencia —HEAD, una rama, una rama de seguimiento remota— cambia de valor, Git escribe una línea en un fichero de texto anotando de dónde venía, adónde va, quién lo hizo y por qué.

Míralo directamente:

Cada línea tiene: hash anterior, hash nuevo, identidad, marca de tiempo, y descripción de la operación. Es texto plano, sin magia.

La estructura de directorios:

Y aquí está la clave de todo el módulo. Recupera la idea de la lección 09-01:

Un commit sobrevive mientras algo lo alcance. Las entradas del reflog cuentan como referencias.

Por eso git gc no elimina un commit que aparece en el reflog, aunque ninguna rama lo apunte. El reflog no es solo un registro: es lo que mantiene vivos los objetos huérfanos. Esa es la razón técnica de que la recuperación funcione.

Antes del recetario, las dos limitaciones. No entenderlas es lo que hace que alguien confíe en el reflog cuando no debe.

El reflog no viaja. No se publica con push, no se descarga con fetch, y un git clone no lo trae.

Una sola entrada. Todo el historial de movimientos que Ana tenía en su máquina se queda en su máquina.

Tres consecuencias prácticas:

1. El reflog de Ana no puede rescatar el desastre de Bruno. Cada uno tiene el suyo.
2. El reflog no es una copia de seguridad. Si el disco muere, muere con él. Las copias de seguridad reales son git bundle y los propios clones del equipo (lección 09-05).
3. Un clon recién hecho no tiene red de seguridad. El primer reset --hard desafortunado en un clon nuevo sí puede dejarte sin nada que recuperar, porque no hay entradas anteriores.

Y una consecuencia positiva, la del apartado 9 de la lección 09-03: si un compañero fuerza y destruye una rama del servidor, tu reflog de origin/rama conserva dónde estaba, y con él se restaura.

Las entradas caducan. Dos parámetros lo gobiernan:

La segunda es la que importa: los commits realmente huérfanos tienen 30 días. Después, un git gc los purga definitivamente.

La caducidad no ocurre sola: la ejecuta git gc (lección 08-06), que Git lanza automáticamente cuando se acumulan objetos sueltos. En la práctica, tienes semanas, no meses, y desde luego no años.

Puedes alargar el plazo:

Cuesta unos megabytes y compra mucha tranquilidad.

Y lo contrario, que nunca debes ejecutar salvo que sepas exactamente qué haces (lección 08-06):

Cómo se lee:

• HEAD@{0} es siempre lo último que pasó. El orden es del presente hacia el pasado.
• El hash de cada línea es dónde quedó HEAD DESPUÉS de esa operación. Este detalle es crucial y produce el error más frecuente: si quieres el estado anterior a la operación de HEAD@{0}, necesitas el hash de HEAD@{1}.
• La descripción dice qué comando lo provocó.

El vocabulario de las descripciones:

Mucho más limpio que el de HEAD cuando sabes qué rama te interesa, porque no incluye los cambios de rama.

--date=relative es el que más ayuda en una recuperación: "lo tenía justo antes de comer" se traduce directamente a una entrada.

Y git log -g (o --walk-reflogs), que recorre el reflog mostrando cada entrada como un commit completo:

Útil cuando no reconoces un commit por su mensaje y necesitas ver qué ficheros tocaba.

Dos sintaxis que se parecen y significan cosas distintas.

La distinción crítica, y merece un ejemplo:

HEAD~3 recorre el grafo: sigue la cadena de padres. HEAD@{3} recorre tu historia personal: puede estar en otra rama, en un commit huérfano, en cualquier sitio donde hayas estado.

Cuando has hecho un reset, HEAD~1 te lleva al padre del commit actual (que ya no es lo que buscabas) y HEAD@{1} te lleva a donde estabas antes del reset (que sí lo es).

Las formas temporales aceptan expresiones muy naturales:

Y el aviso que Git da cuando te pasas de plazo:

No es un error: te está diciendo que ha usado la entrada más antigua disponible. Si la fecha que pediste es anterior, el resultado no es el que crees.

Todas las recetas del apartado siguiente son el mismo procedimiento. Apréndelo una vez.

El paso 4 es el que hay que interiorizar, y es la diferencia entre una recuperación tranquila y un segundo susto:

git branch es puramente aditivo. Si el hash era el equivocado, borras la rama y pruebas otro. Nada se ha movido. Con reset --hard cada intento fallido añade una capa más de confusión.

Y el paso 3, verificar, evita el error de recuperar el commit equivocado:

Y para inspeccionar sin comprometerse a nada:

La situación. Ana quería quitar un commit y escribió HEAD~3.

No has perdido nada (salvo lo que estuviera sin confirmar, lección 09-02).

HEAD@{1} (9c4e7b2) es la punta que había justo antes del reset.

Recuperado. Ahora, si quieres que GT-241 vuelva a ser eso:

El atajo, si acabas de hacerlo y no has hecho nada más (lección 09-02):

O directamente con la sintaxis del reflog:

Esto cierra la promesa de la lección 03-06.

Primer regalo: Git imprime el hash al borrar. Si lo tienes en el buffer de la terminal, la recuperación es inmediata:

Si has cerrado la terminal, hay dos caminos.

A. El reflog de HEAD (funciona si estuviste en esa rama):

B. Buscar por mensaje entre todos los commits huérfanos (funciona siempre):

O directamente sobre la base de objetos:

Y el detalle importante que se olvida: el reflog de la propia rama se borra con ella.

.git/logs/refs/heads/GT-247 ya no existe. Por eso hay que buscar en el reflog de HEAD, que sí sobrevive.

-D casi nunca es irreversible. Los commits siguen en .git/objects, alcanzables desde el reflog de HEAD, durante al menos 30 días. La promesa de la lección 03-06 queda cumplida.

Y la excepción, para ser honestos: si la rama se creó, se le hicieron commits y se borró sin que HEAD pasara nunca por ella (por ejemplo, con git branch X <hash> y luego git branch -D X), el reflog de HEAD no la registra. En ese caso, git fsck del apartado 7.

Esto cierra la promesa de la lección 05-01.

Bruno hizo un rebase -i de diez commits, aplastó los que no debía y terminó con --continue.

La entrada clave es rebase (start): la anterior a ella es el estado exacto previo al rebase. Aquí, HEAD@{5} → 9c4e7b2.

Los diez commits originales, intactos.

Un atajo que casi nadie conoce: durante un rebase, Git guarda la posición inicial en ORIG_HEAD, y también en una referencia especial:

Y si el rebase aún no ha terminado, la salida es mucho más simple:

Devuelve todo exactamente al estado previo. Úsalo siempre que puedas: es más limpio que recuperar después.

Para comparar el resultado con el original y decidir qué hacer, git range-diff (lección 07-02):

Si acabas de hacerlo y no hay nada encima:

merge siempre escribe ORIG_HEAD antes de fusionar. Es la salida canónica.

Si ya has hecho más cosas encima:

HEAD@{2} es el estado previo a la fusión. Pero cuidado: si vuelves ahí, pierdes también el commit c7e2a91 que hiciste después. Lo correcto es rescatarlo aparte:

Y si el merge ya está publicado, nada de reflog: la respuesta es git revert -m 1 (lección 05-06).

Un caso frecuente y desconcertante: git merge --abort no funciona porque la fusión terminó bien; solo era mala idea. --abort sirve mientras hay conflictos sin resolver, no después.

Carla hizo git commit --amend y se dio cuenta de que ha perdido parte del mensaje original —o peor, de que el commit anterior tenía cambios que el nuevo no.

No has perdido nada. --amend no modifica el commit: crea uno nuevo y mueve la rama (lección 09-01). El original sigue en la base de datos.

HEAD@{1} (8f4c2a9) es el commit original, antes del --amend.

Y las formas de recuperar, según lo que necesites:

Retomando el apartado 5.7 de la lección 09-01: hiciste commits en detached HEAD y te fuiste.

La línea checkout: moving from 9c4e7b2 to main te da el hash de donde saliste.

El reflog registra los movimientos de referencias. Hay objetos que llegan a la base de datos sin que ninguna referencia se mueva, y para esos hace falta la otra herramienta.

Y además crea un directorio con enlaces:

dangling es normal e inofensivo. No es un síntoma de corrupción. Es lo que se espera en cualquier repositorio activo. La distinción entre eso y los errores de verdad (missing, broken link) es la lección 09-05.

Un fsck puede devolver decenas de líneas. El trabajo es identificar cuál es el tuyo.

Eso convierte una lista de hashes en información utilizable. Guárdalo como alias:

Inspección individual, con las herramientas de fontanería de la lección 01-04:

Este es el caso que salva más trabajo del que la gente espera. Si preparaste un fichero con git add y luego lo perdiste, el contenido está en la base de datos (lección 09-01, tabla del apartado 1).

Buscar por una cadena que recuerdes es mucho más eficaz que revisar los blobs uno a uno.

Esto cierra la promesa de la lección 05-04.

Primer regalo, otra vez: drop imprime el hash. Con él:

Y si fue git stash clear, que borra toda la pila sin imprimir nada, hay dos caminos.

A. El reflog del stash, si aún existe:

stash clear borra la referencia, pero el fichero de log a veces sobrevive hasta el siguiente gc. Merece la pena mirarlo primero.

B. Buscar los commits del stash entre los inalcanzables:

Los stashes se reconocen por su mensaje: WIP on <rama>: (los automáticos) o On <rama>: <mensaje> (los que creaste con -m).

Un stash es internamente un commit de fusión con dos o tres padres, y merece verlo porque explica cómo funciona:

Y la recuperación:

Toca ser honestos. Hay dos fronteras que ninguna técnica de esta lección cruza.

Ya lo vimos en la lección 09-01, y es la limitación fundamental:

Cuando estás en uno de los tres últimos casos, Git ya no puede ayudarte. Lo que queda es fuera de Git:

1. El historial local de tu editor. Es la vía que más veces funciona y la que menos se prueba.

• VS Code: paleta de comandos → "Local History: Find Entry to Restore". Guarda versiones de cada fichero que has editado, independientemente de Git.
• IntelliJ / WebStorm / Eclipse: menú contextual del fichero → Local History → Show History. Guarda semanas.
• Vim: si tienes set undofile, el historial de deshacer persiste entre sesiones (:earlier 1h).

2. Copias de seguridad del sistema: Time Machine en macOS, instantáneas de Btrfs/ZFS, versiones anteriores en Windows, copias en la nube.

3. Buscar en /tmp y en los ficheros de intercambio del editor (.swp de Vim, ~ de otros).

Si se ejecutó git gc --prune=now después de que el commit quedara huérfano, el objeto ha desaparecido físicamente. Si además se ejecutó git reflog expire --expire=now --all, no hay ni registro.

Comprueba si aún está antes de rendirte:

Ese mensaje significa que el objeto ya no existe. Pero antes de darlo por perdido, mira fuera de tu máquina:

Esa es la red de seguridad del modelo distribuido, y es el tema central de la lección 09-05.

La quinta es la más infravalorada. Una rama publicada está en dos máquinas. Ningún accidente local puede con eso.

Cierra la lección lo que no hay que hacer.

1. git reflog expire --expire=now --all. Vacía el registro. Todo lo huérfano queda desprotegido.

2. git gc --prune=now. Elimina inmediatamente los objetos inalcanzables. Tiene su uso legítimo (tras un filter-repo de la lección 08-05, donde borrar es justo el objetivo), y ninguno en un día normal.

3. Confiar en el reflog como copia de seguridad. Es local, temporal y muere con el disco. No es una copia de seguridad.

4. Recuperar con reset --hard en lugar de git branch. Cada intento fallido añade confusión. branch no mueve nada.

5. Trabajar meses sin publicar una rama. Un clon nuevo tiene el reflog vacío; una rama sin publicar existe en un solo disco.

Y una comprobación de salud de treinta segundos, para saber si tu red de seguridad está donde crees:

Error 1: no probar git reflog. Es el primer comando ante cualquier "he perdido commits", y la mayoría de la gente no lo ejecuta nunca.

Error 2: confundir HEAD@{1} con HEAD~1. El primero es dónde estabas hace una operación; el segundo es el commit padre. Tras un reset, son cosas completamente distintas.

Error 3: coger el hash de la entrada equivocada. El hash de una línea es dónde quedó HEAD después de esa operación. Para el estado previo a HEAD@{0}, necesitas HEAD@{1}.

Error 4: recuperar con reset --hard en lugar de git branch. Si el hash era el equivocado, con branch borras la rama y pruebas otra; con reset cada intento complica más el estado.

Error 5: creer que el reflog viaja en un clone. No viaja. El clon nuevo tiene una sola entrada y ninguna red de seguridad.

Error 6: confiar en el reflog para siempre. 90 días para lo alcanzable, 30 para lo huérfano, y gc los aplica. En la práctica, semanas.

Error 7: asustarse con los dangling de git fsck. Son normales en cualquier repositorio activo. Lo grave es missing y broken link (lección 09-05).

Error 8: dar por perdido un stash. stash drop imprime el hash, stash clear deja los commits huérfanos, y ambos se recuperan con git fsck --unreachable buscando WIP on.

Error 9: rendirse sin mirar fuera de Git. El historial local del editor recupera lo que Git no puede, y casi nadie lo prueba.

Consejo 1: el patrón es siempre el mismo. Reflog → verificar con git show → git branch rescate <hash>.

Consejo 2: git reflog --date=relative. "Lo tenía antes de comer" se traduce directamente a una entrada.

Consejo 3: define el alias git perdidos. El día que lo necesites no vas a recordar la tubería de fsck y awk.

Consejo 4: git rebase --abort mientras puedas. Mucho más limpio que recuperar después.

Consejo 5: alarga el reflog a un año. Dos líneas de configuración global y unos megabytes.

Consejo 6: publica tus ramas. Una rama en dos máquinas es inmune a los accidentes de una.

Sobre un repositorio de pruebas con app.js, estilos.css e index.html:

1. Crea seis commits en main y una rama GT-241 con tres commits propios.
2. Provoca cuatro desastres seguidos, sin recuperar entre uno y otro: a. git reset --hard HEAD~2 en GT-241. b. git switch main && git branch -D GT-241. c. Un git commit --amend en main que borre parte del mensaje. d. Un git merge de una rama experimental que no querías.
3. Ejecuta git reflog --date=relative y anota, para cada desastre, qué entrada usarías.
4. Recupera las cuatro cosas usando siempre git branch, nunca reset.
5. Verifica cada recuperación con git show --stat y git diff.

1. En un repositorio nuevo, crea tres situaciones: un commit, un fichero preparado con git add, y un fichero modificado solo en disco.
2. Ejecuta git reset --hard HEAD~1.
3. Recupera el commit con el reflog y el fichero preparado con git fsck --lost-found + git cat-file -p.
4. Documenta por qué el tercero es irrecuperable, comprobándolo con git fsck y git reflog.
5. Crea un stash con -u, elimínalo con git stash clear y recupéralo con git fsck --unreachable.
6. Comprueba con git show --format='%p' -s que el stash tiene tres padres e inspecciona cada uno.

1. Crea un repositorio con diez commits y provoca cinco commits huérfanos con reset.
2. Comprueba que aparecen en git fsck --lost-found.
3. Ejecuta git reflog expire --expire=now --all y vuelve a mirar git reflog y git fsck. Explica la diferencia entre las dos salidas.
4. Ejecuta git gc --prune=now y comprueba con git cat-file -t <hash> que los objetos han desaparecido de verdad.
5. Repite el experimento configurando antes gc.reflogExpireUnreachable "1 year" y explica qué cambia.
6. Escribe la comprobación de salud del apartado 10 en un guion e interpreta su salida en un repositorio real tuyo.

Solución 1:

Fíjate en el matiz de (b): tras el reset --hard, GT-241 apuntaba a 6e2b9c7, y eso es lo que borró -D (8a1f6c3 en el ejemplo del mensaje). Pero lo que Ana quiere es el estado previo al reset, 9c4e7b2. El reflog las conserva las dos.

Ninguna de esas operaciones ha movido main. Todo lo que había sigue donde estaba, y ahora además hay tres puntos de acceso a lo recuperado.

Los tres commits, incluidos los dos que el reset --hard había dejado atrás.

El mensaje original, antes de que el --amend lo dejara en chore.

Lo único que aportó el merge indeseado. Para deshacerlo:

Y para restaurar GT-241 de verdad:

Solución 2:

Un solo objeto colgante (el del add), ninguna entrada de reflog, y ni un byte en todo .git. La línea SOLO EN DISCO nunca se convirtió en objeto: no se calculó su SHA, no se comprimió, no se escribió. Git no puede devolver lo que jamás recibió. Las únicas vías serían el historial local del editor o una copia del sistema de ficheros.

Recuperado íntegro, incluido el fichero sin seguimiento.

Tres padres exactamente como decía el apartado 8: HEAD, el índice y los ficheros sin seguimiento. Un stash es un commit, y por eso sobrevive a stash clear.

Solución 3:

La diferencia clave: el reflog está vacío, pero los objetos siguen ahí. reflog expire borra el registro, no los objetos. Todavía se pueden recuperar con fsck... pero ya no sabes cuál era la punta ni en qué orden estaban, porque esa información vivía en el reflog. Recuperable, sí; cómodo, no.

Ahora sí ha desaparecido de verdad. El objeto ya no existe en .git/objects. Ninguna técnica de esta lección lo recupera; solo un clon ajeno o una copia de seguridad.

El gc --prune=now no ha podido purgar nada, porque las entradas del reflog siguen vigentes y el reflog cuenta como referencia. Ese es el mecanismo exacto que mantiene vivos los objetos huérfanos, y por eso alargar la caducidad protege de verdad.

La última línea es la que más información da en un repositorio real: cada rama sin upstream existe en un solo disco.

El reflog es la razón por la que casi nada se pierde en Git, y saberlo cambia por completo la relación con los comandos destructivos.

• El reflog registra cada movimiento de cada referencia, en texto plano bajo .git/logs/. Y no es solo un registro: sus entradas cuentan como referencias, y por eso mantienen vivos los commits que ninguna rama alcanza.
• Es local: no viaja en un clone, no se publica, y muere con el disco. No es una copia de seguridad. Y es temporal: 90 días para lo alcanzable, 30 para lo huérfano, que gc aplica.
• HEAD@{n} no es HEAD~n. El primero recorre tu historia personal de movimientos; el segundo recorre el grafo. Tras un reset, son cosas distintas, y confundirlos es el error más común.
• El patrón de recuperación es siempre el mismo: git reflog → verificar con git show --stat → git branch rescate <hash>. Crear una rama es aditivo y no mueve nada; reset --hard complica cada intento fallido.
• El recetario cubre todo lo que este curso había ido prometiendo: deshacer un reset --hard (entrada anterior al reset:), recuperar una rama borrada con -D (el hash que imprime, o el reflog de HEAD, porque el de la rama se borra con ella), rescatar un rebase (entrada anterior a rebase (start), o --abort si sigue en marcha), deshacer un merge (ORIG_HEAD) y recuperar lo que se llevó un --amend (la entrada commit: anterior).
• Cuando el reflog no basta, git fsck --lost-found: los objetos dangling son normales, y entre ellos están los commits huérfanos y los blobs de un git add que nunca se confirmó. git cat-file -p y git show los inspeccionan.
• Un stash es un commit con dos o tres padres (HEAD, índice, sin seguimiento), y por eso sobrevive a drop y a clear: se busca por WIP on entre los inalcanzables y se devuelve con git stash store.
• Los límites son reales: lo que nunca fue objeto (modificaciones sin add, ficheros borrados por clean) y lo que ya pasó por gc --prune. Ahí solo salvan el historial local del editor, una copia del sistema o el clon de un compañero.
• Y la prevención que hace innecesaria toda la lección: confirmar a menudo, poner un git branch antes de lo arriesgado, stash push -u antes de limpiar, alargar el reflog a un año y publicar las ramas.

Hasta aquí, todo se apoyaba en una premisa: que la base de datos de objetos estuviera sana. Los objetos existían, los hashes cuadraban y Git podía leerlos.

¿Y cuándo no? Cuando git status responde error: object file .git/objects/4f/8a2e6... is empty, cuando una referencia apunta a un objeto que no existe, cuando el índice está corrupto y Git se niega a hacer absolutamente nada. Eso ya no es un problema de referencias mal puestas: es un problema de integridad, y tiene su propio diagnóstico, sus propias reparaciones y —lo más importante— un criterio claro para saber cuándo hay que dejar de intentar arreglarlo y volver a clonar.

Continúa en la lección 09-05: Tratando con Repositorios Corruptos.