Ein Durchlauf des Tutorials Commitete Secrets entfernen: wie Sie ein versehentlich commitetes .env mit git rm --cached und .gitignore aus dem Tracking nehmen, und warum das nicht ausreicht, um es aus der Historie zu löschen.
Dieses Szenario ist der herzstillstand-nahe Moment, ein Passwort in der eigenen Commit-Historie zu entdecken. Sie nehmen die Datei aus dem Tracking und verhindern ihre Rückkehr, und ebenso wichtig: Sie lernen, was das Aus-dem-Tracking-Nehmen behebt und was nicht.
Die Situation
Das Projekt hat zwei Commits. Der zweite, Add environment config, hat eine .env-Datei commitet, die ein echt aussehendes Secret enthält (eine Datenbank-URL mit Passwort). Konfigurationsdateien mit Zugangsdaten sollten niemals von Git getrackt werden.
Das unmittelbare Ziel in diesem Szenario ist, das Tracking für .env zu beenden und sicherzustellen, dass sie nicht erneut commitet werden kann. Die tiefere Lehre ist, dass dies das Secret nicht aus dem Commit entfernt, der es bereits enthält.
Sobald ein Secret commitet wurde, betrachten Sie es als offengelegt. Jeder mit dem Repository und seiner Historie kann es lesen. Aus dem Tracking zu nehmen begrenzt zukünftigen Schaden, macht aber die Vergangenheit nicht ungeschehen.
Die Korrektur Schritt für Schritt
Bestätigen, dass das Secret commitet wurde
git log
git status
Das Log zeigt Add environment config, und Sie sehen, dass .env getrackt wird. Diese Datei hätte nie in Git landen dürfen.
Das Tracking der Datei beenden (auf der Festplatte behalten)
git rm --cached .env
Das entfernt .env aus Gits Tracking, lässt aber die tatsächliche Datei in Ihrem Projekt, damit die Anwendung weiter läuft. Anschließend sieht Git .env als ungetrackte Datei.
Sie ignorieren, damit sie nicht zurückkommt
echo ".env" >> .gitignore
git add .gitignore
.env zu .gitignore hinzuzufügen stellt sicher, dass ein zukünftiges git add sie nicht versehentlich erneut staged.
Die Bereinigung commiten
git commit -m "Stop tracking .env and ignore it"
Das hält die Entfernung und die neue .gitignore fest. Ab hier bleibt .env aus Git heraus.
Was das behebt und was nicht
Es ist wichtig, beim Ergebnis präzise zu sein:
- Behoben:
.env wird nicht mehr getrackt, und .gitignore verhindert das erneute Hinzufügen.
- Nicht behoben: Das Secret lebt weiter im Commit
Add environment config. Wer die Historie liest, kann es weiterhin finden.
Weil das Secret in der Historie bleibt, hat die Reaktion in der Praxis zwei weitere Schritte, die dieses Szenario nicht ausführt: die Zugangsdaten rotieren (als kompromittiert behandeln) und die Historie mit git filter-repo oder BFG umschreiben, um sie aus früheren Commits zu entfernen, anschließend force-push.
Künftig: halten Sie Secrets in einer .env-Datei, die von Anfang an in .gitignore steht, und commiten Sie eine .env.example mit Platzhalterwerten, damit Teammitglieder wissen, welche Variablen nötig sind.
Ein commitetes Secret richtig entfernen: die vollständige Checkliste
Die Datei aus dem Tracking zu nehmen ist nur der erste Schritt. Um ein geleaktes Secret tatsächlich einzudämmen:
- Tracking beenden und ignorieren —
git rm --cached .env, .env zu .gitignore hinzufügen und commiten. Künftige Commits sind sauber.
- Aus der gesamten Historie tilgen — das Secret sitzt weiter in vergangenen Commits. Schreiben Sie jeden Commit mit
git filter-repo (empfohlen) oder dem BFG Repo-Cleaner um und force-pushen Sie anschließend.
- Das Secret rotieren — der wichtigste Schritt. Sobald ein Secret gepusht wurde, behandeln Sie es als kompromittiert und stellen Sie einen neuen Schlüssel oder ein neues Token aus. Es aus der Historie zu entfernen verringert die Offenlegung, kann das Leck aber nicht ungeschehen machen.
- Eine Wiederholung verhindern — Werkzeuge wie
git-secrets oder ein Pre-Commit-Hook können verhindern, dass Secrets überhaupt erst commitet werden.
Der Schritt git rm --cached lässt sich hier im Terminal gefahrlos üben; die Schritte Historie-Umschreiben und Rotieren gehören in ein echtes Repository, mit informiertem Team.