Cómo recuperar un archivo borrado con Git (paso a paso)

Acabas de borrar un archivo que necesitabas y se te encoge el estómago. Respira. Si ese archivo estaba bajo Git, casi seguro que lo recuperas. La pregunta no es si se puede, sino en qué estado lo borraste, porque de eso depende el comando exacto que vas a escribir.

Para seguir esto solo necesitas lo mínimo: haber hecho alguna vez git add y git commit, y saber que un commit es una foto guardada de tus archivos en un momento concreto. Nada más. Voy a separar el rescate en tres situaciones y darte el comando concreto para cada una. Si quieres el mapa completo de cómo deshacer cosas en Git, lo tienes en la guía general para deshacer cambios en Git.

¿Por qué Git suele poder recuperar tu archivo?

Git puede devolverte el archivo porque guarda una copia de todo lo que le has confiado, y esa copia no desaparece cuando borras el archivo de tu carpeta.

Piensa en varios sitios. El primero es tu carpeta del proyecto, los archivos que ves en el explorador y que abre tu editor. En Git eso se llama árbol de trabajo (working tree). Entre esa carpeta y el historial hay una zona intermedia donde Git prepara lo que vas a confirmar, la zona de preparación (staging). Y por último está un almacén interno donde Git guarda cada commit que has hecho. Cuando borras un archivo, lo estás quitando del árbol de trabajo. El almacén sigue teniendo la foto de ese archivo intacta.

Por eso recuperar un archivo borrado en Git es casi siempre posible. Hay una única condición: que el archivo llegara a estar bajo control de Git. Si nunca hiciste git add de él, Git no sabe que existió y no hay ninguna foto que rescatar. Ten esa condición en la cabeza, porque es la que marca la diferencia entre “esto se arregla en diez segundos” y “esto no se puede”.

Primer paso: averigua en qué estado está el borrado

Antes de escribir ningún comando de rescate, ejecuta git status. Te dice si el borrado sigue solo en tu carpeta o si ya lo has guardado dentro de un commit.

# Muestra el estado actual del repositorio
git status

Si el archivo lo borraste pero aún no lo has confirmado, verás algo así:

Changes not staged for commit:
  (use "git restore <file>..." to discard changes in working directory)
        deleted:    notas.txt

Esa línea deleted: notas.txt es toda la información que necesitas: Git sabe que el archivo existía y detecta que ya no está en tu carpeta. Estás en el caso más fácil.

Si en cambio git status te dice nothing to commit, working tree clean y el archivo no aparece por ningún lado, significa que el borrado ya viajó dentro de un commit. Cambia el rescate, pero el archivo sigue estando. Vamos caso por caso.

Caso 1: lo borraste pero aún no habías hecho commit

Si git status muestra el archivo como deleted: y no has hecho commit del borrado, git restore <archivo> lo devuelve tal como estaba en el último commit.

# Devuelve notas.txt a como estaba en el último commit
git restore notas.txt

Y listo. El archivo vuelve a tu carpeta. git restore es la forma moderna de hacer esto: se introdujo en Git 2.23 (2019) precisamente para separar la tarea de “recuperar archivos” de la de “cambiar de rama”, que antes se mezclaban en git checkout. Si trabajas con una versión antigua de Git y restore no existe, el equivalente clásico es git checkout -- notas.txt.

Hay un matiz. El comando de arriba funciona cuando solo borraste el archivo. Si además marcaste ese borrado para el commit (con git add notas.txt o con git rm notas.txt), tienes que recuperarlo también en la zona de preparación:

# Deshace el borrado tanto en la zona de preparación como en tu carpeta
git restore --staged --worktree notas.txt

Caso 2: borraste el archivo y ya commiteaste el borrado

Si ya hiciste commit del borrado, el archivo no está en el último commit, pero sigue vivo en uno anterior. Lo traes de vuelta con git restore --source ^[2].

HEAD es el nombre que Git le da a tu último commit. HEAD~1 es el de justo antes. Así que para recuperar el archivo desde el commit anterior:

# Restaura notas.txt desde el commit anterior al último (HEAD~1)
git restore --source=HEAD~1 notas.txt

¿Y si el borrado no fue en el último commit, sino hace varios? Necesitas encontrar en qué commit desapareció. Para eso git log tiene un filtro que lista solo los commits donde se borró ese archivo:

# Lista los commits que borraron notas.txt (D = deleted)
git log --diff-filter=D -- notas.txt

Eso te devuelve el hash del commit que hizo el borrado, algo como a1b2c3d. El archivo existía justo antes, en el commit padre, que se escribe añadiendo ^ al hash. Recupéralo desde ahí:

# a1b2c3d es el commit que borró el archivo; su padre (a1b2c3d^) todavía lo tenía
git restore --source=a1b2c3d^ notas.txt

También puedes recuperar el mismo contenido con git checkout a1b2c3d^ -- notas.txt. La diferencia es que checkout además deja el archivo preparado (staged), mientras que git restore solo toca tu carpeta; me quedo con restore porque su nombre dice exactamente lo que hace.

Caso 3: el archivo se perdió y no encuentras el commit

Si no encuentras el commit donde el archivo aún existía, git reflog te da una segunda oportunidad. Es la situación típica después de un reset agresivo, un rebase que salió mal o una rama que borraste sin querer: el commit ya no aparece en git log, pero Git todavía se acuerda de dónde estuvo.

El reflog es un registro local de cada posición por la que ha pasado HEAD, incluidas las que ya no salen en el historial normal. Vive solo en tu máquina y no se comparte al hacer push.

# Muestra el historial de movimientos de HEAD
git reflog

Verás una lista con hashes y una descripción de cada movimiento:

a1b2c3d HEAD@{0}: reset: moving to HEAD~3
f9e8d7c HEAD@{1}: commit: añadir notas del proyecto
c3d4e5f HEAD@{2}: commit: primera versión

Busca el commit donde el archivo todavía existía (aquí f9e8d7c, el del mensaje “añadir notas del proyecto”) y restaura el archivo desde ahí:

# Recupera notas.txt desde el commit que localizaste en el reflog
git restore --source=f9e8d7c notas.txt

Git conserva estas entradas del reflog durante unos 90 días por defecto para los commits alcanzables ^[1]. Si el commit se quedó sin ninguna rama que lo señale, el caso típico tras un reset --hard o una rama borrada, el margen real es más corto: unos 30 días ^[1]. En cuanto detectes el borrado, recupéralo. Si quieres entender a fondo cómo funciona este registro y qué más puedes rescatar con él, míralo en el post sobre el reflog como red de seguridad de Git.

Practícalo sin miedo a romper nada

La mejor forma de perderle el miedo a borrar archivos es borrar uno a propósito, en un repo de prueba, y recuperarlo tú. Crea un archivo cualquiera, haz commit, bórralo y prueba los comandos de arriba hasta que el rescate te salga sin pensar. Pruébalo aquí mismo, sin instalar nada:

Cargando ejercicio...

¿Qué comando usar en cada situación?

Cuando tengas prisa, esta tabla es el resumen. Localiza tu situación en la primera columna y copia el comando.

Situación	Comando	Qué recupera
Lo borraste, sin commit todavía	git restore <archivo>	La versión del último commit
Ya commiteaste el borrado	git restore --source=HEAD~1 <archivo>	La versión del commit anterior
Se perdió y no está en git log	git reflog y luego git restore --source=<hash> <archivo>	La versión del estado que localices en el reflog
Estaba dentro de un stash guardado	git stash list y luego git checkout stash@{0} -- <archivo>	La versión que guardaste en ese stash

Errores comunes al recuperar archivos

Tirar de git reset --hard esperando “deshacer”

Este es el error que más trabajo destruye. Cuando alguien entra en pánico, es tentador escribir git reset --hard porque suena a “vuelve todo atrás”. El problema es que ese comando reescribe tu árbol de trabajo entero y descarta cambios que no habías guardado, así que puedes perder mucho más de lo que intentabas recuperar. Para un archivo concreto no necesitas nada tan agresivo: git restore toca solo ese archivo. Si dudas entre reset, revert y restore, la comparación está en las diferencias entre reset, revert y restore.

Creer que git commit -a iba a salvar un archivo nuevo

git commit -a (o git commit -am) solo confirma cambios de archivos que Git ya estaba siguiendo. Un archivo nuevo que nunca pasó por git add es invisible para ese atajo, y no se confirma ni se recupera con él.

Buscar el mensaje del commit con git blame

git blame te dice quién tocó cada línea por última vez y en qué commit, con su hash, autor y fecha. Lo que no te muestra es el mensaje del commit. Si lo que buscas es entender por qué desapareció el archivo, usa el hash que te da blame y pásaselo a git show <hash> o mira git log, que sí muestran el mensaje completo.

Culpar a Git de un archivo que nunca guardaste

Si cerraste el editor sin guardar, o borraste un archivo que jamás añadiste con git add, Git no puede ayudarte. Solo recupera lo que en algún momento llegó a estar trackeado o commiteado. Git no falla aquí: simplemente nunca le diste ese archivo para que lo guardara.

Recuperar un archivo borrado es solo una de las muchas veces que Git te va a salvar. Si quieres dejar de trabajar con miedo a romper algo y entender de verdad qué hace cada comando, en el curso Git de cero a profesional practicas estos rescates y muchos más en un entorno interactivo, paso a paso y sin tocar tu proyecto real. Y aunque todavía no te lances con el curso, puedo seguir echándote una mano por correo.

¿Quieres más guías prácticas de Git como esta? Déjame tu correo y te aviso cuando publique una nueva:

Un concepto nuevo cada semana

Suscribirme

Fuentes

1. Documentación oficial de git reflog (git-scm.com): comportamiento del reflog y expiración por defecto de las entradas (90 días para las alcanzables).
2. Documentación oficial de git restore (git-scm.com): opción --source y fuente por defecto al restaurar archivos.

Preguntas Frecuentes

¿Puedo recuperar un archivo borrado en Git que nunca añadí con git add?

No. Git solo guarda copias de los archivos que en algún momento pasaron por git add y quedaron dentro de un commit. Si creaste un archivo, lo borraste y nunca lo añadiste, para Git ese archivo no existió nunca y no hay nada que restaurar. Por eso conviene hacer commits pequeños y frecuentes: es tu red de seguridad.

¿git restore y git checkout hacen lo mismo?

Sí, para recuperar un archivo. git restore se introdujo en Git 2.23 como forma moderna y recomendada, separando la recuperación de archivos del cambio de ramas, que ahora hace git switch. git checkout -- <archivo> sigue funcionando y verás mucho contenido antiguo que lo usa, pero si tu Git es reciente, prefiere git restore porque es más claro sobre lo que va a tocar.

¿Qué pasa si ya hice git push del borrado?

El archivo sigue recuperable en tu historial local con los mismos comandos de este post. Recupéralo, haz un commit nuevo que lo vuelva a añadir y haz push de ese commit:

# Recupera el archivo, vuelve a confirmarlo y sube ese commit nuevo
git restore <archivo>
git add <archivo>
git commit -m "Recuperar <archivo>"
git push

Así el archivo regresa sin reescribir la historia que ya compartiste con el resto del equipo, que es lo que evita problemas con tus compañeros.

¿Cuánto tiempo guarda Git el archivo en el reflog?

Por defecto, Git conserva las entradas del reflog unos 90 días para los commits que siguen siendo alcanzables, y unos 30 días para los que ya no lo son ^[1]. Es tiempo de sobra para la mayoría de rescates, pero no lo dejes para dentro de tres meses: en cuanto detectes el borrado, recupéralo.

¿git restore sobrescribe los cambios que tengo ahora mismo?

Sí, y por eso hay que tener cuidado. git restore <archivo> reemplaza la versión actual de ese archivo en tu carpeta por la que recupera, y los cambios sin guardar de ese archivo se pierden. Si no estás seguro, haz antes un commit o un git stash de lo que tengas, y así trabajas sobre una copia guardada en vez de sobre el original.