Dateien aus Git entfernen

Das Löschen einer Datei ist in Git ein eigenständiger, protokollierter Vorgang – kein Nebeneffekt des Dateisystems. Wer eine Datei einfach im Explorer oder in PhpStorm löscht, hat Git davon zunächst nichts mitgeteilt. Dieser Abschnitt zeigt, wie Löschvorgänge korrekt vorgemerkt, committet und in unterschiedlichen Varianten durchgeführt werden.

Löschen im Dateisystem versus Löschen in Git

Wenn du eine Datei manuell löschst, meldet git status sie als geänderte, aber nicht vorgemerkte Datei:

del beispiel.txt
git status

Changes not staged for commit:
  deleted:    beispiel.txt

Git erkennt zwar, dass die Datei fehlt, hat die Löschung aber noch nicht in den Index übernommen. Erst ein zusätzlicher git add – oder besser gleich git rm – macht die Löschung Teil des nächsten Commits.

git rm: Löschen und Vormerken in einem Schritt

Der saubere Weg führt über git rm. Der Befehl entfernt die Datei gleichzeitig aus dem Arbeitsverzeichnis und aus dem Index:

git rm beispiel.txt

rm 'beispiel.txt'

Ein anschließendes git status zeigt die Datei bereits als vorgemerkt zum Löschen (staged: deleted). Ein Commit schließt den Vorgang ab:

git commit -m "Entferne veraltete Datei beispiel.txt"

Nur aus der Versionskontrolle entfernen, Datei behalten

Häufig soll eine Datei nicht mehr von Git verfolgt werden, aber weiterhin lokal existieren – etwa eine Konfigurationsdatei mit lokalen Einstellungen oder eine versehentlich committete .env-Datei. Dafür gibt es die Option --cached:

git rm --cached config.local.php

Dieser Befehl entfernt die Datei ausschließlich aus dem Index. Im Arbeitsverzeichnis bleibt sie unverändert erhalten, taucht danach aber als nicht verfolgt auf. In Kombination mit einem passenden Eintrag in .gitignore verschwindet sie danach dauerhaft aus zukünftigen Vorschlägen von git status.

Praxistipp: Diese Kombination – git rm --cached gefolgt von einem .gitignore-Eintrag – ist der Standardweg, um versehentlich eingecheckte Zugangsdaten oder generierte Dateien nachträglich aus der Nachverfolgung zu entfernen. Die vollständige Entfernung aus der Historie erfordert dagegen weiterführende Werkzeuge, die in späteren Kapiteln behandelt werden.

Bereits gelöschte Dateien nachträglich stagen

Wurde eine Datei bereits klassisch gelöscht, bevor du an git rm gedacht hast, musst du das Repository nicht zurücksetzen. git add merkt auch Löschungen korrekt vor:

git add beispiel.txt

Git erkennt, dass die Datei fehlt, und merkt diesen Zustand als Löschung vor – der Effekt ist identisch zu git rm.

Verzeichnisse rekursiv entfernen

Soll ein ganzes Verzeichnis samt Inhalt entfernt werden, ist die Option -r erforderlich:

git rm -r temp/

Ohne diese Option verweigert Git die Operation, um versehentliches Löschen ganzer Verzeichnisbäume zu verhindern.

Löschung erzwingen

Enthält eine Datei nicht committete Änderungen, verweigert git rm standardmäßig die Löschung, um Datenverlust zu vermeiden:

error: the following file has local modifications:
    beispiel.txt

Mit der Option -f (force) wird die Löschung dennoch durchgeführt:

git rm -f beispiel.txt

Diese Schutzmechanik ist bewusst restriktiv gestaltet – ein typisches Beispiel für Gits generelle Haltung, lieber einen expliziten zusätzlichen Schritt zu verlangen, als Arbeit unwiderruflich zu verwerfen.

Übersicht der wichtigsten Varianten

Befehl	Wirkung auf Arbeitsverzeichnis	Wirkung auf Index
git rm datei	Datei wird gelöscht	Löschung vorgemerkt
git rm --cached datei	Datei bleibt erhalten	Löschung vorgemerkt
git rm -r verzeichnis/	Verzeichnis wird gelöscht	Löschung vorgemerkt
git rm -f datei	Datei wird trotz Änderungen gelöscht	Löschung vorgemerkt
Manuelles Löschen + git add	Datei bereits gelöscht	Löschung nachträglich vorgemerkt

Ausblick auf PhpStorm

PhpStorm bildet diese Vorgänge grafisch nach: Ein Löschen einer Datei im Project-Werkzeugfenster fragt automatisch, ob die Löschung auch in Git vorgemerkt werden soll, und übernimmt intern denselben git rm-Mechanismus. Wie dieser Ablauf konkret aussieht und sich in die übrige IDE-Bedienung einfügt, zeigt der letzte Abschnitt dieses Kapitels, in dem der gesamte bisherige Workflow noch einmal vollständig innerhalb von PhpStorm nachvollzogen wird.