Was Sie jetzt sofort tun sollten
- Prüfen Sie den Papierkorb und klonen Sie das Repository erneut, falls es auf ein Remote gepusht wurde.
- Ist der .git-Ordner erhalten, holen Sie Dateien und Commits mit git restore, git reflog und git stash zurück.
- Für nicht committete Arbeit prüfen Sie die Zeitachse in VS Code oder Local History in JetBrains, bevor Sie das Laufwerk vom USB-Stick aus scannen.
Schritt für Schritt
Builds stoppen und Papierkorb prüfen
Führen Sie auf diesem Laufwerk keine Paketinstallationen, Builds oder Tests aus, denn sie schreiben Tausende Dateien. Sehen Sie zuerst in den Papierkorb: Was im Explorer oder in vielen IDEs gelöscht wird, landet meist dort, Befehle wie rm -rf, del, Remove-Item oder git clean umgehen ihn dagegen.
Vom Remote neu klonen
Wurde das Projekt zu GitHub, GitLab oder einem anderen Server gepusht, klonen Sie es in einen neuen Ordner. Alles Committete und Gepushte kommt exakt zurück. Es fehlt nur lokale Arbeit, die nie gepusht wurde.
Git nutzen, wenn .git erhalten ist
Wurden nur einzelne Dateien gelöscht, listet git status sie auf, und git restore mit dem Pfad holt meist ihren letzten committeten Stand zurück. Nach einem versehentlichen git reset --hard zeigt git reflog frühere Commits, zu denen Sie zurückkehren können. Prüfen Sie git stash list auf beiseitegelegte Arbeit. Dateien, die mit git add vorgemerkt, aber nie committet wurden, finden sich manchmal mit git fsck --lost-found.
Lokalen Verlauf des Editors prüfen
Öffnen Sie in VS Code die Zeitachse einer Datei; der lokale Verlauf wird getrennt vom Projekt gespeichert. Bei einer gelöschten Datei lässt eine leere Datei unter demselben Pfad oft die früheren Einträge erscheinen. In JetBrains-IDEs klicken Sie mit der rechten Maustaste auf den Projektordner und öffnen Local History und dann Show History; dort sind gelöschte Dateien aufgeführt und lassen sich zurücksetzen.
Laufwerk nach dem Ordner durchsuchen
Starten Sie die portable Version von FileFix Ultimate vom USB-Stick, öffnen Sie Gelöschte Dateien wiederherstellen, wählen Sie das Laufwerk und starten Sie den Ausgewogenen Scan. Navigieren Sie im Ordnerbaum zum Projektpfad oder filtern Sie nach Endungen wie cs, py, js, ts oder java. Abhängigkeits- und Build-Ordner überspringen Sie, sie lassen sich neu erzeugen.
Woanders speichern und Code prüfen
Speichern Sie den wiederhergestellten Ordner auf einem anderen physischen Datenträger. Öffnen Sie ihn dort, lassen Sie Build und Tests laufen und vergleichen Sie mit git diff gegen das Remote, denn eine teilweise überschriebene Datei kann auf den ersten Blick plausibel wirken.
Warum git einen Laufwerksscan meist schlägt
Der .git-Ordner enthält komprimiert jede committete Fassung jeder verfolgten Datei. Solange er lokal oder auf einem Remote existiert, ist committeter Code nicht wirklich verloren, es braucht nur den richtigen Befehl. Deshalb schmerzt das Löschen eines Projektordners mit .git mehr als das Löschen einzelner Dateien: Ohne Push ist auch die Historie weg.
Nicht committete Änderungen sind etwas anderes. Git hat sie nie gesehen, realistische Quellen sind daher der lokale Verlauf des Editors, seine Sicherungen ungespeicherter Tabs und das Laufwerk selbst. Die Suche nach ungespeicherten Dateien in FileFix Ultimate findet auch Sicherungskopien von VS Code und Notepad++, die Code aus Tabs enthalten können, die beim Schließen des Editors offen waren.
Was ein Scan mit Quelldateien kann und was nicht
Fotos und Dokumente beginnen mit einem erkennbaren Kopf, deshalb findet eine Signatursuche sie, auch wenn das Dateisystem sie vergessen hat. Quellcode ist reiner Text ohne solchen Kopf. Für Code hängt alles an den Einträgen des Dateisystems: Sind die NTFS-Einträge des gelöschten Ordners erhalten, kommen Namen, Pfade und Ordnerstruktur gemeinsam zurück; wurden sie wiederverwendet, sind die Textdateien praktisch nicht auffindbar.
Sehr kleine Dateien speichert NTFS oft direkt in ihrem Dateieintrag, weshalb kurze Konfigurations- und Quelldateien manchmal überleben, wenn große verloren sind. Binäre Bestandteile des Projekts wie Bilder, Archive oder SQLite-Datenbanken lassen sich per Signatur finden, allerdings ohne Namen.
Projekte in WSL oder virtuellen Maschinen
Code in WSL 2 liegt in einer virtuellen Festplattendatei, meist ext4.vhdx genannt, die ein ext4-Dateisystem enthält. Führen Sie wsl --shutdown aus, kopieren Sie die Datei auf einen anderen Datenträger und öffnen Sie die Kopie; FileFix Ultimate kann VHDX-Abbilder öffnen und ext4 schreibgeschützt lesen. In ext4 gelöschte Dateien lassen sich schwerer mit Namen zurückholen als unter NTFS, sehen Sie das also als Chance, nicht als sicheren Weg. VMDK-, VHDX- und QCOW2-Datenträger virtueller Maschinen öffnen Sie genauso.
Wann es nicht funktioniert
- Die meisten Entwicklungsrechner nutzen eine SSD mit TRIM, die gelöschte Dateien fast sofort löschen kann; nicht committeter Code ist dann womöglich endgültig verloren.
- Lief nach dem Löschen eine Paketinstallation oder ein Build auf demselben Laufwerk, wurde der freie Platz wahrscheinlich neu belegt.
- Ohne erhaltene Einträge des Dateisystems lassen sich Quelldateien aus reinem Text nicht per Signatur finden.
- Arbeit, die nie committet, gepusht oder vom Editorverlauf erfasst wurde, hat nach dem Überschreiben keine Kopie mehr.
So hilft FileFix Ultimate
- Für die private Nutzung kostenlos und ohne Limit (geschäftlich mit Jahreslizenz pro PC), mit einer portablen Version für den USB-Stick, damit auf das Entwicklungslaufwerk nichts Neues geschrieben wird.
- Baut gelöschte Ordnerbäume aus NTFS-, FAT32- und exFAT-Einträgen wieder auf und behält Dateinamen und Pfade, wo diese Einträge noch existieren.
- Findet mit der Suche nach ungespeicherten Dateien Sicherungen von VS Code und Notepad++ aus ungespeicherten Editor-Tabs.
- Öffnet VHDX-, VMDK- und QCOW2-Abbilder und liest ext4 schreibgeschützt für Code in WSL oder virtuellen Maschinen.
FileFix Ultimate ist für die private Nutzung kostenlos, arbeitet offline und schreibt nie auf das Laufwerk, von dem Sie wiederherstellen. Die geschäftliche Nutzung erfordert eine Jahreslizenz pro PC. Prüfen Sie die Signatur, bevor Sie es ausführen.
Häufig gestellte Fragen
Ich habe git reset --hard ausgeführt. Bekomme ich meine Commits zurück?
Meistens ja. Führen Sie git reflog aus, suchen Sie den Commit vor dem Reset und legen Sie darauf einen Branch an oder setzen Sie dorthin zurück. Nie committete Änderungen stehen nicht im Reflog; nur vorgemerkte lassen sich eventuell mit git fsck finden.
Verschiebt git clean Dateien in den Papierkorb?
Nein. git clean löscht nicht verfolgte Dateien direkt, sie erscheinen also nicht im Papierkorb. Es bleiben der lokale Verlauf des Editors oder ein Laufwerksscan.
Soll ich node_modules und Build-Ordner auch wiederherstellen?
Nein. Sie entstehen aus den Projektdateien und der Lock-Datei neu, deshalb ist es schneller und sicherer, sie nach der Rückkehr des Quellcodes neu zu installieren. Ohne sie wird die Wiederherstellung außerdem kleiner und schneller zu prüfen.
Behalten die wiederhergestellten Dateien ihre Namen und Ordner?
Wenn sie über die Einträge des Dateisystems gefunden werden, ja. Quelldateien lassen sich auf anderem Weg nicht finden, eine Datei im Ordnerbaum erscheint daher in der Regel mit ihrem Namen.