Recuperación de cambios en Git

Usa esta guía cuando hayas perdido cambios, borrado commits o necesites rescatar trabajo que no llegó a consolidarse. Cubre los casos más comunes de recuperación real: cambios en staging, commits perdidos, stash, reflog y fsck.

important

Esta página sirve para rescatar trabajo perdido. No explica el flujo normal de trabajo ni la configuración inicial del repositorio.

1) Identifica primero qué estado tenían tus cambios

Antes de ejecutar cualquier comando, aclara en qué punto estaba el trabajo perdido:

Solo hiciste ****git add: los cambios estaban en el staging area.
Hiciste ****git commit: el trabajo llegó a formar parte del historial.
Usaste ****git stash: el trabajo fue guardado temporalmente.
Nunca hiciste git add ni ****git stash: la recuperación depende más del editor, del sistema operativo o de herramientas externas.

warning

Cuanto más “limpio” quedó el repo después del accidente, más fácil suele ser recuperar. Si el espacio de objetos fue reutilizado o el archivo nunca llegó a Git, la recuperación puede no ser posible.

2) Caso 1: hiciste `git add` pero no `commit`

Si añadiste cambios al staging area y después ejecutaste algo como git reset --hard o un cambio de contexto que borró el estado visible, todavía puedes intentar recuperar los objetos huérfanos.

Qué significa

Los cambios llegaron a Git como objetos de contenido.
Puede que ya no estén referenciados por una rama o por HEAD.
git fsck puede encontrar esos blobs y dejarlos disponibles para inspección.

Cómo recuperarlo

git fsck --lost-found

Esto busca objetos huérfanos y los deja en:

.git/lost-found/other/

Los archivos suelen aparecer sin nombre original, pero con el contenido intacto.

validated

Si el archivo recuperado no tiene nombre, abre su contenido y compáralo con tu trabajo esperado para identificar cuál corresponde.

critical

git fsck no reconstruye automáticamente el nombre ni la ubicación original del archivo. Solo ayuda a encontrar contenido que todavía existe en la base de objetos de Git.

3) Caso 2: hiciste `git commit`, pero después lo perdiste

Si el cambio llegó a commit, la recuperación suele ser mucho más simple, porque Git guarda referencias de movimientos recientes incluso cuando el commit deja de estar apuntado por una rama.

3.1 Ver el historial reciente de `HEAD`

git reflog

Ejemplo de salida:

a7332c0 HEAD@{0}: reset: moving to HEAD~2
3bd8179 HEAD@{1}: commit: Update

reflog muestra dónde estuvo HEAD recientemente, incluso si ya no aparece en el historial normal.

3.2 Recuperar el commit encontrado

Cuando identifiques el commit correcto, tienes dos opciones:

git checkout 3bd8179

Esto te lleva a ese commit en modo inspección.

Si quieres dejarlo como estado actual del repositorio:

git reset --hard 3bd8179

warning

git reset --hard descarta el estado actual del directorio de trabajo y del staging area. Úsalo solo cuando estés seguro de que quieres reemplazar todo por ese commit.

3.3 Cuándo `reflog` sí y no sirve

reflog es útil cuando:

hiciste reset
moviste HEAD
perdiste un commit reciente
borraste una referencia local, pero el commit todavía existe en el almacén de objetos

reflog no ayuda si:

el commit nunca existió
el repositorio fue clonado de nuevo sin ese historial local
pasó demasiado tiempo y la referencia ya expiró
la basura interna de Git ya eliminó el objeto

validated

Si recuperaste el commit correcto, puedes crear una branch temporal desde él antes de hacer cualquier cambio adicional.

4) Caso 3: hiciste `git stash`

Si guardaste el trabajo con stash, la recuperación es directa.

Ver los stashes disponibles

git stash list

Aplicar el stash más reciente

git stash apply stash@{0}

Aplicar y borrar el stash al mismo tiempo

git stash pop stash@{0}

tip

apply conserva el stash en la lista. pop lo aplica y lo elimina si no hay conflictos.

Cuándo `stash` aplica y cuándo no

stash solo sirve si realmente ejecutaste git stash antes del problema. No recupera cambios que:

nunca llegaron a stash
fueron sobrescritos por otro guardado
ya no están en la lista de stashes porque se eliminaron o caducaron

5) Caso 4: viste los cambios en verde en VSCode

Si VSCode mostraba los cambios en verde, normalmente significa que estaban en el staging area.

Eso implica que Git ya había registrado esos cambios como preparados para commit, por lo que:

cerrar VSCode no los borra
apagar el PC no los borra
cambiar de ventana no los borra

Lo que sí puede afectarlos es una operación de Git que reescriba el estado, como:

git reset --hard
git checkout sobre el mismo archivo
otra acción que elimine referencias al contenido

validated

En términos prácticos, “verde” suele significar que Git todavía conoce el contenido, aunque ya no veas el archivo en su ubicación original.

6) Caso 5: nunca hiciste `git add`

Si el cambio solo existió en el editor y nunca se añadió al staging, Git normalmente no puede recuperarlo por sí solo.

En ese caso, revisa primero:

historial local del editor
autosave o historial de versiones
archivos temporales del sistema operativo
papelera o snapshots del entorno

critical

Si el cambio nunca pasó por Git, git fsck, reflog y stash probablemente no servirán.

7) Flujo recomendado de rescate

Ejecuta git status para confirmar el estado actual.
Si el cambio estuvo staged, prueba git fsck --lost-found.
Si hubo commits, revisa git reflog.
Si usaste stash, lista y reaplica el stash.
Si no apareció nada, revisa el editor o el sistema operativo.

important

Si encuentras un commit o un blob correcto, evita seguir probando comandos destructivos antes de copiar o aislar la recuperación.

8) Diagnóstico rápido por síntomas

Síntoma	Qué mirar primero	Comando principal	Resultado esperado
Solo hiciste `git add`	Objetos huérfanos	`git fsck --lost-found`	Recuperar blobs todavía existentes
Hiciste `git commit` y luego lo perdiste	Movimientos recientes de `HEAD`	`git reflog`	Volver a un commit reciente
Guardaste trabajo con `git stash`	Lista de stashes	`git stash list`	Reaplicar cambios guardados
Ves cambios en verde en VSCode	Estado staged	`git fsck --lost-found`	Confirmar si el contenido sigue en Git
Nunca hiciste `git add`	Editor o sistema operativo	N/A	Buscar autosave, historial o snapshots

9) Resumen rápido

fsck: busca contenido huérfano cuando hubo staging sin commit.
reflog: rescata commits que todavía existen en el historial local.
stash: reaplica trabajo guardado explícitamente.
checkout** y ****reset --hard**: pueden servir para inspeccionar o volver a un punto conocido, pero también pueden borrar estado actual si se usan sin cuidado.

tip

Si quieres, esta misma estructura se puede ampliar con un bloque de “diagnóstico por síntomas” para decidir el comando correcto en menos de 30 segundos.

- EOF -