.gitignore wird ignoriert – weil die Datei längst getrackt ist
Der Eintrag in .gitignore wirkt nicht? Dann kennt Git die Datei schon. Mit git rm --cached raus aus dem Index – und was das nicht heilt.
Aufwand:
ca. 10 Min.
Voraussetzung:
Git, Terminal, Texteditor
Gilt für:
Git (alle aktuellen Versionen)
Das Symptom
In der .gitignore steht .env. Oder node_modules/. Oder dist/. Trotzdem
listet git status die Datei brav weiter auf, jede Änderung daran will
committet werden, und der Build-Ordner wandert bei jedem Push wieder mit ins
Remote. Der Eintrag ist richtig geschrieben, die Datei liegt am richtigen Ort,
und Git tut trotzdem so, als hätte niemand etwas gesagt.
Die „Layer 8“-Wahrheit
Die .gitignore ist keine Sperre, sondern eine Empfehlung für Neuankömmlinge.
Sie legt fest, welche absichtlich nicht verfolgten Dateien Git ignorieren
soll – bereits verfolgte Dateien sind davon ausdrücklich nicht betroffen. Das
steht wörtlich in der Dokumentation, direkt im ersten Absatz, und es beschreibt
den gesamten Fehler: Irgendwann in der Vergangenheit hat ein git add . die
Datei in den Index geschoben, meistens bevor die .gitignore existierte. Ab
diesem Moment ist sie Teil des Bestands, und eine Regel für Unbekannte gilt für
Bekannte eben nicht. Der Ausweg ist ein Zweizeiler: mit git rm --cached den
Indexeintrag entfernen, ohne die Datei anzufassen, dann die Regel greifen
lassen. Die Dokumentation empfiehlt exakt diese Reihenfolge. Was dieser
Zweizeiler jedoch nicht tut – und das wird verlässlich falsch verstanden – ist
die Vergangenheit anzufassen. Ein Schlüssel, der in Commit 47 steht, steht auch
danach noch in Commit 47, auf jedem Rechner, der jemals geklont hat. Wer sein
Geheimnis für gerettet hält, weil git status schweigt, hat den Unterschied
zwischen Aufräumen und Vertuschen nicht verstanden.
Die echte, verifizierte Lösung
1000 % faktenbasiert. Jeder Befehl ist real, jeder Pfad existiert. Schritt für Schritt:
1.
Prüfen, ob die Datei wirklich getrackt ist
Erst die Diagnose, dann der Hammer. Gibt der Befehl den Pfad aus, kennt Git die Datei – dann ist der Index das Problem und nicht die Regel. Bleibt die Ausgabe leer, liegt es am Muster in der .gitignore:
git ls-files .env
git check-ignore -v .env
2.
Die Datei aus dem Index nehmen, nicht von der Platte
Mit --cached verschwindet nur der Indexeintrag, die Datei bleibt im Arbeitsverzeichnis liegen. Bei Ordnern zusätzlich -r für rekursiv. Genau so beschreibt es die Git-Dokumentation als Weg, das Verfolgen einer Datei zu beenden:
Jetzt erst wird der Eintrag wirksam, weil die Datei ab sofort unverfolgt ist. Ordner bekommen einen abschließenden Schrägstrich, damit das Muster nur auf Verzeichnisse passt:
.env
.env.local
node_modules/
dist/
4.
Alles zusammen committen
Der Commit enthält zwei Dinge: die Entfernung aus dem Index und die neue Regel. Beides gehört zusammen, sonst zieht der nächste git add . die Datei wieder herein:
git add .gitignore
git commit -m "Build-Artefakte und .env nicht mehr verfolgen"
5.
Nachkontrollieren, dass Ruhe eingekehrt ist
git status darf die Datei nicht mehr anzeigen, git ls-files sie nicht mehr auflisten. Erst wenn beides stimmt, ist der Eintrag tatsächlich wirksam:
git status
git ls-files .env node_modules
6.
Bei Geheimnissen zusätzlich rotieren
Standen in der Datei Zugangsdaten, ein Token oder ein Schlüssel und wurde sie jemals gepusht, ist dieses Geheimnis kompromittiert. Es steht weiterhin in jedem älteren Commit und in jedem Klon. Also: beim Anbieter widerrufen, neu ausstellen, den neuen Wert nur noch außerhalb des Repositories ablegen. Alles andere ist Kosmetik.
Häufige Fragen (FAQ)
?Warum ignoriert Git meine Datei nicht, obwohl sie in .gitignore steht?
Weil .gitignore nur über Dateien entscheidet, die Git noch nicht kennt. Die Dokumentation sagt es in einem Satz: Eine gitignore-Datei legt absichtlich nicht verfolgte Dateien fest, die Git ignorieren soll – bereits von Git verfolgte Dateien sind davon nicht betroffen. Sobald eine Datei einmal im Index gelandet ist, etwa durch ein unbedachtes git add ., ist sie für Git eine verfolgte Datei, und jede Änderung daran taucht weiterhin in git status auf. Der Eintrag ist also nicht falsch, er kommt nur zu spät.
?Löscht git rm --cached meine Datei von der Festplatte?
Nein. Die Option --cached entfernt den Eintrag aus dem Index, nicht aus dem Arbeitsverzeichnis. Deine .env liegt danach unverändert an ihrem Platz, Git hört nur auf, sie zu beobachten. Genau dieses Vorgehen empfiehlt die Git-Dokumentation: Um eine derzeit verfolgte Datei nicht mehr zu verfolgen, entfernt man sie mit git rm --cached aus dem Index; danach kann der Dateiname in die .gitignore eingetragen werden, damit sie in späteren Commits nicht wieder auftaucht. Wichtig: Im nächsten Commit steht die Datei als gelöscht – wer sie danach frisch klont, hat sie nicht mehr. Das ist bei .env und node_modules gewollt, bei einer Konfigurationsvorlage nicht.
?Ist mein API-Schlüssel jetzt sicher, wenn ich ihn aus dem Index nehme?
Nein, und das ist der wichtigste Satz auf dieser Seite. git rm --cached ändert nur, wie es ab dem nächsten Commit weitergeht. Jeder ältere Commit, der die Datei enthält, enthält sie weiterhin – lokal, im Remote, in jedem Klon, in jedem Fork, in jedem CI-Cache. Wurde das Geheimnis schon einmal gepusht, ist die einzig verlässliche Reaktion, es zu widerrufen und neu auszustellen. Historie umschreiben kann man zusätzlich tun, aber es ersetzt das Rotieren nicht.
?Wie finde ich heraus, welche Regel überhaupt greift?
Mit git check-ignore -v <pfad>. Der Befehl nennt Datei, Zeilennummer und die konkrete Regel, die auf den Pfad passt – oder er gibt gar nichts aus, wenn keine Regel greift. Das beantwortet die zweithäufigste Ursache: kein Tracking-Problem, sondern ein Muster, das nicht passt, weil ein führender Schrägstrich es an das Wurzelverzeichnis bindet oder eine Negation weiter unten es wieder aufhebt.
Belege
Diese Seite ist gegen die folgenden Primärquellen geprüft – Hersteller, Standard oder Gesetzestext. Wer es nicht glaubt, muss es nicht: Da steht, wo es nachzulesen ist.
Der Diff markiert jede Zeile als geändert, obwohl nur ein Wort angepasst wurde? Zeilenenden. Windows und Unix streiten sich um ein unsichtbares Zeichen.
Git meldet „detached HEAD“? Du stehst nicht auf einem Branch, sondern direkt auf einem Commit — Änderungen hier gehen ohne Gegenmaßnahme leicht verloren.
git commit bricht mit „gpg failed to sign the data“ ab? Meist fehlt der passende Schlüssel, oder GPG kann im Terminal nicht nach der Passphrase fragen.