Git Untracked Files löschen: Sicheres git clean // mrsaynothing

TL;DR: Untracked files in git löschst du mit git clean -fd — aber schau immer vorher mit git clean -nd, denn clean löscht endgültig, nichts landet im Papierkorb. -f für Dateien, -fd für Dateien und Verzeichnisse, -fdx, wenn auch gitignorierter Build-Output weg soll. Die häufigste Klage — „git clean löscht meine untracked files nicht” — heißt fast immer: Die Dateien liegen in einem untracked Verzeichnis (nimm -d dazu) oder es sind ignorierte Dateien (nimm -x dazu). Untracked-Überbleibsel sind der normale Nebeneffekt von Experimenten, Builds und Skripten rund ums Klonen; dieser Guide zeigt, wie du jede Löschung vorher ansiehst, Dateien nur aus einem Verzeichnis entfernst und welche Kombinationen du in einem Repo, das dir etwas bedeutet, nie ausführst.

Was bedeutet „untracked” bei git status?

Untracked heißt: git sieht die Datei auf der Platte, aber niemand hat ihm gesagt, sie zu tracken — sie liegt nicht im Index und hat keine Commit-History. git status sortiert alles in drei Eimer:

$ git status --short
 M src/app.ts        # geändert: getrackt, verändert
?? notes.txt         # untracked: neue Datei, die git nicht kennt
?? build/            # untracked-Verzeichnis: komplett neu für git

Diese Unterscheidung ist wichtig, weil jeder Eimer ein anderes Werkzeug zum Entfernen braucht. Getrackte, aber geänderte Dateien machst du mit git restore rückgängig oder commitest sie weg — git clean fasst sie nicht an. Nur die ??-Zeilen sind git clean-Revier. Ignorierte Dateien (alles, was .gitignore matcht) sind der versteckte vierte Eimer: Sie erscheinen nicht mal als ??, und git clean überspringt sie, solange du nicht per -x ausdrücklich zustimmst.

Wenn dein eigentliches Problem eine getrackte Datei ist, die nie ins Commit hätte sollen, ist Clean das falsche Werkzeug — das ist ein Job für git rm --cached oder ein Reset des letzten Commits, wie in git undo last commit: keep the changes beschrieben.

Wie lösche ich untracked files in git?

Der Kernbefehl ist git clean -f. Ohne -f verweigert git jede Löschung und druckt nur eine Warnung — ein absichtliches Sicherheitsgeländer. Die volle Routine:

# 1. Genau ansehen, was gelöscht wird (Dry-Run — löscht nichts)
git clean -nd

# Würde löschen:
# notes.txt
# build/
# scratch/

# 2. Prüfen, dass nichts Kostbares in der Liste liegt, dann wirklich löschen
git clean -fd

Flag für Flag:

-f / --force — Pflicht. Löscht untracked files tatsächlich.
-d — steigt in untracked Verzeichnisse hinab. Bloßes -f entfernt nur untracked Dateien auf der obersten Ebene und meldet die Verzeichnisse, die es sich verweigert hat.
-n / --dry-run — zeigt, was entfernt würde. Immer zuerst ausführen.
-x — löscht auch ignorierte Dateien (node_modules, Build-Output, .env).
-X — löscht nur ignorierte Dateien und lässt untracked-nicht-ignorierte stehen.
-i — interaktiver Modus; nützlich, wenn die Dry-Run-Liste lang ist.

Eine Gewohnheit zum Übernehmen: Behandle git clean -nd wie git diff — vor dem Commit schaust du hin, vor dem Clean ebenfalls.

Warum löscht git clean meine untracked files nicht?

Drei echte Ursachen, sortiert danach, wie oft sie zubeißen:

1. Die Dateien liegen in einem untracked Verzeichnis. Mit nur -f entfernt git lose untracked Dateien, bleibt aber an Verzeichnissen hängen — meldet sogar Would remove build/, löscht es im echten Lauf aber nicht. Nimm -d dazu:

git clean -fd

2. Die Dateien sind gitignored. node_modules/, dist/, .venv/ — ignorierte Pfade sind für ein nacktes Clean unsichtbar. Der Dry-Run listet sie nicht auf, und das Clean entfernt sie erst recht. Ausdrücklich zustimmen:

git clean -fdx   # untracked + ignorierte Dateien und Verzeichnisse

3. Ein verschachteltes git-Repository oder ein Submodule steht im Weg. Git löscht nie den Inhalt eines fremden Repos von außen. Entferne das Submodule sauber oder gib --force zweimal (git clean -ffd) — ersteres ist vorzuziehen.

Wenn der Dry-Run nichts listet, git status aber ??-Einträge zeigt, bist du vermutlich im falschen Working Tree — wirf git rev-parse --show-toplevel an und prüfe, dass du in dem Repo bist, das du räumen wolltest.

Wie lösche ich untracked files nur in einem bestimmten Verzeichnis?

Gib dem Clean einen Pfad mit — alles andere bleibt unberührt:

git clean -fd build/          # nur innerhalb von build/
git clean -fd src/generated   # ein bestimmter Teilbaum

Das ist die Antwort auf „Ich will die untracked files und Ordner in build/ loswerden, aber meine Notizen im Repo-Root behalten”. Der Pfad ist relativ zu deinem aktuellen Verzeichnis: vom Repo-Root aus gilt das ganze Repo, aus einem Unterverzeichnis heraus nur dieser Teilbaum.

Wie bekomme ich untracked files aus dem Baum, ohne sie zu löschen?

Wenn der Dry-Run Dateien zeigt, die du vielleicht später brauchst: nicht wetten — erst sichern, dann räumen:

# Untracked files stashen (ignorierte mit -a inklusive), ohne zu löschen
git stash push --include-untracked
git clean -fd                      # der Baum ist sauber
git stash pop                      # bei Bedarf zurückholen

git stash -u holt untracked files aus dem Baum und hält sie wiederherstellbar — genau diese Semantik von „entfernen ohne löschen” suchen die meisten. Für eine behaltbare Vorschau gibt dir git clean -nd > clean-plan.txt die exakte Liste, bevor du dich festlegst. Nach git clean -f gibt es kein Undo: gelöscht heißt weg.

git clean vs. git rm vs. git restore: was wofür?

Befehl	Fasst an	Löscht von der Platte	Einsetzen, wenn
`git clean -fd`	Untracked Dateien/Verzeichnisse	Ja	Dateien löschen, die git nie getrackt hat
`git clean -fdx`	Untracked + ignorierte	Ja	Kompletter Reset inklusive `node_modules`, Build-Output
`git rm <file>`	Getrackte Dateien	Ja (gestaged)	Eine Datei löschen und die Löschung in git festhalten
`git rm --cached <file>`	Getrackte Dateien	Nein	Eine Datei nicht mehr tracken, auf der Platte behalten
`git restore <file>`	Getrackte Dateien	Nein	Lokale Änderungen verwerfen, Datei behalten

Die Einzeiler-Regel: Clean verwaltet, was git nicht kennt; rm und restore, was es kennt. Wer sie verwechselt, verliert Arbeit — etwa wenn git clean -fdx läuft, während man glaubt, es benehme sich wie git restore.

Was solltest du mit git clean niemals anfassen?

Zwei Angewohnheiten, die sofort gestrichen werden:

Niemals git clean -fdx blind in einem Monorepo oder Workspace laufen lassen. Es löscht jedes ignorierte Verzeichnis — jedes node_modules, jedes virtualenv, jede lokale .env im Baum. Zurück gibt es sie unter Umständen erst nach einer Stunde Neuinstallation, und eine gelöschte .env ist womöglich gar nicht wiederzubekommen.
Niemals einen Alias mit eingebautem Force anlegen. git config alias.wipe "clean -fd" fühlt sich effizient an, bis du dich im Pfad vertippst. Halte den Dry-Run einen Tastendruck entfernt (git clean -nd) und mach ein Zwei-Befehle-Ritual daraus: erst ansehen, dann löschen.

Nützlich zu wissen: Untracked files direkt vor einem [sync a fork with upstream]-Pull zu räumen hält die Merge-Fläche klein — ein sauberer Baum ist die billigste Konfliktversicherung, die es gibt: sync a fork with upstream, step by step.

Der sichere git-clean-Workflow, komprimiert

git status --short        # was liegt im Baum?
git clean -nd             # Vorschau: was WÜRDE wegfliegen?
git clean -fd             # untracked Dateien + Verzeichnisse löschen
git clean -fdX            # (optional) nur ignorierten Build-Output räumen
git status --short        # prüfen: Working Tree clean

Vorschau, löschen, prüfen — dreißig Sekunden, null Bedauern, und git status zeigt endlich wieder sauber an.

Git Untracked Files löschen: Sicheres git clean