Cómo recuperar un alijo de Git caído, una rama eliminada o confirmaciones perdidas

Cuando sueltas un alijo o eliminas una rama, Git elimina el nombre, no las confirmaciones. Las confirmaciones permanecen en el repositorio como objetos inalcanzables hasta que la recolección de basura los elimina, generalmente después de dos semanas o más. Encuentre la última confirmación de una rama eliminada en el registro nuevo con git reflog, busque un alijo eliminado con git fsck --unreachable, compruébelo con git show y luego guárdelo con git branch rescue <sha>.

Esta guía cubre cada caso con los comandos exactos, explica durante cuánto tiempo Git mantiene el trabajo perdido y qué no se puede recuperar, y muestra la misma recuperación en Lost & Found de GitTree, que busca en todas las fuentes a la vez y nunca verifica ni restablece nada. Lost & Found es parte del plan gratuito de GitTree. Para deshacer un reinicio, un rebase o una modificación, lea cómo deshacer git reset, rebase y commit en su lugar.

Dónde vive realmente el trabajo "perdido" de Git

Se puede alcanzar una confirmación cuando una rama, una etiqueta, el alijo o HEAD conducen a ella. Eliminar una rama o soltar un alijo hace que sus confirmaciones sean inalcanzables, pero permanecen en .git/objects. Dos registros te ayudan a encontrarlos: el reflog, donde apuntaba cada rama y HEAD antes, y la base de datos de objetos en sí, que git fsck puede buscar.

Recuperar una rama eliminada

Git imprime la última confirmación de la rama cuando la eliminas (Deleted branch feature/login (was 3f2a9c1)). Si ese mensaje desapareció, busque en el registro de HEAD la última vez que estuvo en la rama, luego vuelva a crear la rama en esa confirmación.

# find the last commit of the branch
git reflog | grep "feature/login"

# check what it holds
git show 3f2a9c1 --stat

# put the branch back
git branch feature/login 3f2a9c1

Recuperar un alijo caído

Un alijo no tiene reflog propio una vez que se elimina, así que busque las confirmaciones inalcanzables. Un alijo es una confirmación en forma de combinación cuyo mensaje comienza con WIP on o On <branch>:, lo que facilita su filtrado. Este es el método que describe la propia documentación oculta de Git.

# list unreachable stash-like commits, newest first
git fsck --unreachable | grep commit | cut -d" " -f3 \
  | xargs git log --merges --no-walk --grep=WIP --format="%h %cr %s"

# inspect a candidate
git stash show -p 7c1e0b4

# restore it into your working tree, or keep it on a branch
git stash apply 7c1e0b4
git branch rescue-stash 7c1e0b4

Encuentre cada confirmación pendiente con git fsck --lost-found

git fsck --lost-found enumera las confirmaciones pendientes y escribe una copia de cada una en .git/lost-found/commit/, denominada por su ID. Úsalo cuando no sepas lo que estás buscando: enuméralos con sus fechas y mensajes, luego pasa del que deseas.

git fsck --lost-found
ls .git/lost-found/commit | xargs git log --no-walk --format="%h %cr %s"
git branch rescue 9d44b0e

¿Cuánto tiempo mantiene Git las confirmaciones perdidas?

La recolección de basura se ejecuta por sí sola después de algunos comandos, por lo que son ventanas, no promesas. Cuanto antes miras, más encuentras. Una copia en otro lugar, como el clon de un compañero de equipo o una rama enviada, es la otra red de seguridad: el trabajo perdido sólo en tu computadora existe sólo allí.

Lo que no se puede recuperar

• Cambios que nunca se confirmaron o guardaron, como ediciones descartadas con git checkout -- <file> o git restore.
• Archivos sin seguimiento que no estaban en un alijo creado con -u.
• Confirma que la recolección de basura ya se ha podado.
• Trabajo que sólo existió en la computadora de otra persona.

Próximos pasos: la guía de objetos perdidos documenta cada página y botón, buscar consejos sobre ramas anteriores cubre la vista de registro y la guía de git stash explica cómo aplicar, abrir y archivos sin seguimiento para que necesites recuperarlos con menos frecuencia.