Übersicht
git rm [-f] [-r] [--cached] [--] <file>...
Beschreibung
Der git rm-Befehl entfernt Dateien in einem Schritt aus dem Working Tree und dem Index und staget die Löschung für den nächsten Commit. Die Verwendung von git rm ist bequemer als das Entfernen der Datei mit rm und anschließendem git add — auch wenn beide Ansätze denselben Endzustand erzeugen.
Das --cached-Flag ist besonders nützlich: Es entfernt die Datei aus dem Index, ohne sie aus dem Working Tree zu löschen. Es ist das richtige Werkzeug, wenn Sie versehentlich eine Datei committet haben (etwa eine Konfigurationsdatei mit Geheimnissen oder ein Build-Artefakt) und das Tracking beenden, sie aber auf der Festplatte behalten wollen.
Im täglichen Einsatz integriert sich git rm eng mit Shell-Aliasen, Editor-Plugins und Continuous Integration. Power-User fügen oft Aliase hinzu, die Flags kombinieren, die sie immer übergeben, oder wickeln den Befehl in Skripte, die Teamkonventionen durchsetzen. Die Ausgabeformatierung kann über Git-Config angepasst werden — Pretty-Formate, Farbschemata und Pager-Verhalten sind alle einstellbar. Wenn etwas schiefgeht, ist der erste Diagnoseschritt üblicherweise, den Befehl erneut mit GIT_TRACE=1 in der Umgebung auszuführen, was die zugrunde liegenden Plumbing-Aufrufe offenlegt. Für ungewöhnliche Situationen öffnet die --help-Ausgabe (git rm --help) die vollständige Manpage mit Details zu jeder Option, einschließlich solcher, die in alltäglichen Workflows selten verwendet werden, aber für Debugging oder Skripting im großen Maßstab essentiell sind.
Zu verstehen, wie git rm mit dem Rest von Gits Datenmodell interagiert — der Objektdatenbank, dem Index, Refs und dem Working Tree — zahlt sich aus. Jeder Befehl operiert auf einer Teilmenge dieser Stücke, und zu wissen, welche er berührt, hilft Ergebnisse vorherzusagen und sich von Fehlern zu erholen. Das Lesen der offiziellen Git-Dokumentation neben praktischer Übung in einem Wegwerf-Repository ist der schnellste Weg, die Nuancen zu verinnerlichen. Die meisten Produktionsprobleme mit Git rühren von einer von drei Ursachen: überraschendem Standardverhalten, partiellen Netzwerkoperationen oder dem Umschreiben bereits geteilter Historie. Ein funktionierendes mentales Modell der Nebenwirkungen von git rm hilft, alle drei zu vermeiden.
Häufige Optionen
| Option | Beschreibung |
|---|---|
-f, --force | Überschreibt Sicherheitsprüfungen, wenn die Datei uncommitted Änderungen enthält. |
-r | Entfernt Verzeichnisse rekursiv. |
--cached | Entfernt nur aus dem Index; lässt die Datei im Working Tree unverändert. |
-n, --dry-run | Zeigt, was entfernt würde, ohne es zu tun. |
--ignore-unmatch | Beendet sich mit Null-Status, auch wenn keine Dateien passen. |
-q, --quiet | Unterdrückt Ausgabe. |
Beispiele
git rm old-file.txt
# Datei löschen und Löschung stagen
git rm -r build/
# Verzeichnis rekursiv aus dem Repo entfernen
git rm --cached secrets.env
# Tracking einer Datei beenden, sie aber lokal behalten
# Anschließend zu .gitignore hinzufügen!
git rm -n '*.log'
# Vorschau, welche Logdateien entfernt würden
Häufige Fehler
Der größte Fallstrick: Vergessen, dass git rm --cached nur künftiges Tracking beendet — vergangene Commits enthalten die Datei weiterhin. Wenn Sie ein Geheimnis aus der Historie entfernen müssen, verwenden Sie git filter-repo oder BFG. Ein weiterer Fehler ist das Ausführen von git rm auf einer Datei mit unstaged Modifikationen, ohne zu merken, dass diese Änderungen verloren gehen. Verwenden Sie im Zweifel zuerst -n.
Verwandte Befehle
git add, git mv, git restore, git filter-repo