Cómo recuperar una carpeta de código fuente o de proyecto borrada

Paso a paso

1. Detenga las compilaciones y mire la papelera

   No ejecute instalaciones de paquetes, compilaciones ni pruebas en esa unidad, porque escriben miles de archivos. Mire primero la papelera de reciclaje: lo que se borra desde el Explorador o desde muchos IDE suele ir allí, mientras que comandos como rm -rf, del, Remove-Item o git clean la omiten.

2. Vuelva a clonar desde el remoto

   Si el proyecto se subió a GitHub, GitLab u otro servidor, clónelo de nuevo en una carpeta nueva. Todo lo que tenía commit y push vuelve exactamente igual. Lo que sigue faltando es el trabajo local que nunca se subió.

3. Use git si sobrevivió la carpeta .git

   Si solo se borraron algunos archivos, git status los muestra y git restore seguido de la ruta suele traer su última versión confirmada. Tras un git reset --hard por error, git reflog muestra los commits anteriores a los que puede volver. Revise git stash list por si apartó trabajo. Los archivos preparados con git add pero sin commit a veces se encuentran con git fsck --lost-found.

4. Revise el historial local del editor

   En VS Code, abra la vista Escala de tiempo de un archivo; el historial local se guarda aparte del proyecto. Para un archivo borrado, crear un archivo vacío con la misma ruta suele hacer que aparezcan sus entradas anteriores. En los IDE de JetBrains, haga clic derecho en la carpeta del proyecto y abra Local History y después Show History, donde los archivos borrados aparecen y se pueden revertir.

5. Analice la unidad en busca de la carpeta

   Ejecute la versión portátil de FileFix Ultimate desde un USB, abra Recuperar archivos borrados, elija la unidad e inicie el Análisis equilibrado. Recorra el árbol de carpetas hasta la ruta del proyecto o filtre por extensiones como cs, py, js, ts o java. Omita las carpetas de dependencias y de compilación, que se pueden regenerar.

6. Guarde en otro sitio y verifique el código

   Guarde la carpeta recuperada en otro disco físico. Ábrala en la nueva ubicación, ejecute la compilación y las pruebas, y compárela con el remoto mediante git diff, porque un archivo que volvió en parte sobrescrito puede parecer correcto a primera vista.

Por qué git suele ganar a un análisis del disco

La carpeta .git guarda, comprimidas, todas las versiones confirmadas de cada archivo rastreado. Mientras exista, en local o en un remoto, el código confirmado no está realmente perdido: recuperarlo es cuestión del comando adecuado. Por eso borrar una carpeta de proyecto que contenía .git duele más que borrar unos pocos archivos, ya que el historial se fue con ella si no se había subido.

Los cambios sin commit son otra cosa. Git nunca los vio, así que las fuentes realistas son el historial local del editor, las copias de seguridad de pestañas sin guardar y el propio disco. La búsqueda de archivos sin guardar de FileFix Ultimate también busca copias de respaldo de VS Code y Notepad++, que pueden contener código de pestañas abiertas cuando se cerró el editor.

Lo que un análisis puede y no puede hacer con el código fuente

Las fotos y los documentos empiezan con un encabezado reconocible, de modo que una búsqueda por firmas los encuentra aunque el sistema de archivos los haya olvidado. El código fuente es texto plano sin ese encabezado. Para el código, todo depende de los registros del sistema de archivos: si sobreviven las entradas NTFS de la carpeta borrada, vuelven juntos los nombres, las rutas y la estructura; si se reutilizaron, los archivos de texto prácticamente no se pueden encontrar.

En NTFS, los archivos muy pequeños suelen guardarse dentro de su propio registro, por eso a veces sobreviven archivos cortos de configuración y de código cuando los grandes no. Los recursos binarios del proyecto, como imágenes, archivos comprimidos o bases de datos SQLite, sí se encuentran por firma, aunque sin nombre.

Proyectos dentro de WSL o de máquinas virtuales

El código guardado dentro de WSL 2 vive en un archivo de disco virtual, normalmente llamado ext4.vhdx, que contiene un sistema de archivos ext4. Ejecute wsl --shutdown, copie ese archivo a otro disco y abra la copia; FileFix Ultimate puede abrir imágenes VHDX y leer ext4 en modo de solo lectura. Los archivos borrados en ext4 son más difíciles de recuperar con nombre que en NTFS, así que tómelo como una oportunidad y no como una vía segura. Los discos VMDK, VHDX y QCOW2 de máquinas virtuales se abren de la misma forma.

Cuándo no funcionará

• La mayoría de los equipos de desarrollo usan un SSD con TRIM, que puede borrar los archivos eliminados casi de inmediato; el código sin commit puede perderse para siempre.
• Si después del borrado se ejecutó una instalación de paquetes o una compilación en la misma unidad, es probable que el espacio libre se haya reutilizado.
• Sin registros del sistema de archivos, los archivos de código en texto plano no se pueden encontrar por firma.
• El trabajo que nunca tuvo commit, push ni historial del editor no tiene copia a la que volver una vez sobrescrito el espacio.

Cómo ayuda FileFix Ultimate

• Sin límites y gratis para uso personal, con una versión portátil que se ejecuta desde USB para no escribir nada nuevo en la unidad de desarrollo.
• Reconstruye árboles de carpetas borrados a partir de registros NTFS, FAT32 y exFAT, conservando nombres y rutas cuando esos registros existen.
• Encuentra con la búsqueda de archivos sin guardar las copias de respaldo de VS Code y Notepad++ de pestañas sin guardar.
• Abre imágenes VHDX, VMDK y QCOW2 y lee ext4 en modo de solo lectura para el código guardado en WSL o en máquinas virtuales.

Preguntas frecuentes