O que fazer agora
- Confira a Lixeira e, se o projeto foi enviado a um remoto, clone o repositório de novo.
- Se a pasta .git sobreviveu, use git restore, git reflog e git stash para trazer de volta arquivos e commits.
- Para trabalho sem commit, veja a Linha do Tempo do VS Code ou o Local History da JetBrains antes de verificar a unidade a partir de um pendrive.
Passo a passo
Pare os builds e confira a Lixeira
Não rode instalações de pacotes, builds nem testes nessa unidade, porque eles gravam milhares de arquivos. Olhe a Lixeira primeiro: o que é excluído pelo Explorador ou por muitas IDEs costuma ir para lá, enquanto comandos como rm -rf, del, Remove-Item ou git clean passam por cima dela.
Clone de novo a partir do remoto
Se o projeto foi enviado ao GitHub, GitLab ou outro servidor, clone-o de novo em uma pasta nova. Tudo o que teve commit e push volta exatamente igual. O que continua faltando é o trabalho local que nunca foi enviado.
Use o git se a pasta .git sobreviveu
Se só alguns arquivos foram excluídos, git status os lista e git restore seguido do caminho normalmente traz a última versão com commit. Depois de um git reset --hard por engano, git reflog mostra commits anteriores para onde você pode voltar. Confira git stash list para trabalho guardado. Arquivos preparados com git add mas nunca commitados às vezes aparecem com git fsck --lost-found.
Confira o histórico local do editor
No VS Code, abra a Linha do Tempo de um arquivo; o histórico local fica guardado separado do projeto. Para um arquivo excluído, criar um arquivo vazio no mesmo caminho costuma fazer as entradas antigas aparecerem. Nas IDEs da JetBrains, clique com o botão direito na pasta do projeto e abra Local History e depois Show History, onde os arquivos excluídos aparecem e podem ser revertidos.
Verifique a unidade em busca da pasta
Execute a versão portátil do FileFix Ultimate em um pendrive, abra Recuperar arquivos excluídos, escolha a unidade e inicie a Verificação equilibrada. Navegue pela árvore de pastas até o caminho do projeto ou filtre por extensões como cs, py, js, ts ou java. Pule as pastas de dependências e de build; elas podem ser geradas de novo.
Salve em outro lugar e confira o código
Salve a pasta recuperada em outro disco físico. Abra-a no novo local, rode o build e os testes e compare com o remoto usando git diff, porque um arquivo que voltou parcialmente sobrescrito pode parecer correto à primeira vista.
Por que o git costuma ganhar de uma verificação de disco
A pasta .git guarda, comprimidas, todas as versões com commit de cada arquivo rastreado. Enquanto ela existir, no PC ou em um remoto, o código com commit não está realmente perdido: recuperá-lo é questão do comando certo. Por isso excluir uma pasta de projeto que continha .git dói mais do que excluir alguns arquivos, já que o histórico foi junto se não havia push.
Mudanças sem commit são outra história. O git nunca as viu, então as fontes realistas são o histórico local do editor, os backups de abas não salvas e o próprio disco. A busca de arquivos não salvos do FileFix Ultimate também procura cópias de backup do VS Code e do Notepad++, que podem guardar código de abas abertas quando o editor fechou.
O que uma verificação consegue e não consegue com código-fonte
Fotos e documentos começam com um cabeçalho reconhecível, então uma busca por assinatura os encontra mesmo quando o sistema de arquivos os esqueceu. Código-fonte é texto puro sem esse cabeçalho. Para código, tudo depende dos registros do sistema de arquivos: se as entradas NTFS da pasta excluída sobreviveram, nomes, caminhos e estrutura voltam juntos; se foram reutilizadas, os arquivos de texto praticamente não podem ser encontrados.
No NTFS, arquivos muito pequenos costumam ficar guardados dentro do próprio registro, e por isso arquivos curtos de configuração e de código às vezes sobrevivem quando os grandes não. Recursos binários do projeto, como imagens, arquivos compactados ou bancos SQLite, ainda podem ser encontrados por assinatura, mas sem o nome.
Projetos dentro do WSL ou de máquinas virtuais
Código guardado dentro do WSL 2 fica em um arquivo de disco virtual, normalmente chamado ext4.vhdx, que contém um sistema de arquivos ext4. Rode wsl --shutdown, copie esse arquivo para outro disco e abra a cópia; o FileFix Ultimate abre imagens VHDX e lê ext4 somente para leitura. Arquivos excluídos no ext4 são mais difíceis de recuperar com nome do que no NTFS, então encare isso como uma chance, não como um caminho certo. Discos VMDK, VHDX e QCOW2 de máquinas virtuais abrem do mesmo jeito.
Quando não vai funcionar
- A maioria dos computadores de desenvolvimento usa SSD com TRIM, que pode apagar arquivos excluídos quase na hora; o código sem commit pode se perder de vez.
- Se uma instalação de pacotes ou um build rodou na mesma unidade depois da exclusão, o espaço livre provavelmente foi reutilizado.
- Sem registros do sistema de arquivos, arquivos de código em texto puro não podem ser encontrados por assinatura.
- Trabalho que nunca teve commit, push nem histórico do editor não tem cópia para onde voltar depois que o espaço é sobrescrito.
Como o FileFix Ultimate ajuda
- Gratuito para uso pessoal e sem limites (uso profissional com licença anual por PC), com versão portátil que roda do pendrive para não gravar nada novo na unidade de desenvolvimento.
- Reconstrói árvores de pastas excluídas a partir dos registros NTFS, FAT32 e exFAT, mantendo nomes e caminhos quando esses registros existem.
- Encontra, com a busca de arquivos não salvos, backups do VS Code e do Notepad++ de abas que nunca foram salvas.
- Abre imagens VHDX, VMDK e QCOW2 e lê ext4 somente para leitura para código guardado no WSL ou em máquinas virtuais.
FileFix Ultimate é grátis para uso pessoal, funciona offline e nunca grava na unidade da qual você está recuperando dados. O uso profissional exige uma licença anual por PC. Verifique a assinatura antes de executá-lo.
Perguntas frequentes
Rodei git reset --hard. Consigo meus commits de volta?
Normalmente sim. Rode git reflog, encontre o commit de antes do reset e crie um branch nele ou volte para ele. Mudanças que nunca tiveram commit não estão no reflog; só as preparadas podem aparecer com git fsck.
O git clean manda os arquivos para a Lixeira?
Não. O git clean exclui arquivos não rastreados diretamente, então eles não aparecem na Lixeira. Restam o histórico local do editor ou uma verificação do disco.
Devo recuperar node_modules e as pastas de build também?
Não. Elas são geradas a partir dos arquivos do projeto e do arquivo de lock, então é mais rápido e seguro reinstalá-las depois que o código voltar. Deixá-las de fora também deixa a recuperação menor e mais rápida de conferir.
Os arquivos recuperados mantêm nomes e pastas?
Quando são encontrados pelos registros do sistema de arquivos, sim. Arquivos de código não podem ser encontrados de outra forma, então um arquivo que aparece na árvore de pastas normalmente aparece com o nome.