Gitignore funktioniert nicht? Der echte Fix

TL;DR: Wenn .gitignore nicht funktioniert, ist die Datei fast immer schon getrackt. Git ignoriert Dateien, die es nie gesehen hat — eine Datei im Index ist immun gegen jede Regel, die du auch schreibst. Die Wahrheit liefert git check-ignore -v <path>: Schweigen heißt, der Pfad ist getrackt und keine Regel greift. Fix: git rm --cached <path>, committen, und die Ignore-Regel greift ab diesem Commit. Regelreihenfolge, Negations-Fallen und die VS-Code-Scheinprobleme erklären die restlichen Fälle.

Warum funktioniert .gitignore nicht?

Ein Mechanismus deckt die Mehrheit der Fälle ab: Die Datei wurde committed, bevor die Regel existierte. .gitignore ist kein Filter, der Dateien vor git versteckt — es ist eine Regel darüber, was git add aus dem ungetrackten Zustand aufnehmen soll. Sobald eine Datei im Index ist, verfolgt git ihre Inhaltsänderungen bis auf Weiteres, bis du sie explizit enttrackst. .gitignore im Nachhinein zu bearbeiten ändert nichts an getrackten Dateien — deshalb liefert die klassische Sequenz „.env committen, Panik, .env in .gitignore aufnehmen, nochmal committen” das Secret bei jedem Push weiter aus.

Das erwischt alle, weil git fast universell ist — die Stack-Overflow-Umfrage 2022 bezifferte die Git-Nutzung auf über 93 % der professionellen Entwickler (survey.stackoverflow.co) — und jeder einzelne dieser Entwickler schreibt irgendwann eine Regel für eine Datei, die er letzte Woche committet hat.

Der Rest dieses Beitrags behandelt die Minderheitenfälle: Fehler in der Reihenfolge, Negations-Fallen, Ordner-Sonderfälle und die IDE-Frage. Aber fahr zuerst den Health-Check im nächsten Abschnitt — in mehr als neun von zehn Fällen beendet er die Suche.

Wie prüfe ich, welche Gitignore-Regel auf eine Datei passt?

git check-ignore ist das Diagnosewerkzeug, und sein Schweigen ist die Diagnose:

# Gibt die passende Regel + Datei + Zeilennummer aus, wenn eine Regel greift
git check-ignore -v debug.log
# .gitignore:3:*.log    debug.log

# Gibt NICHTS aus, wenn keine Regel greift — die Datei ist getrackt (oder es gibt keine Regel)
git check-ignore -v src/.env
# (Schweigen = .gitignore ignoriert diesen Pfad nicht, was auch immer du geschrieben hast)

# Exit-Codes: 0 = ignoriert, 1 = nicht ignoriert — skriptbar
git check-ignore -q debug.log && echo "ignored" || echo "tracked or unruly"

Die -v-Ausgabe lesen: zuerst die Ignore-Quelle (.gitignore, .git/info/exclude oder deine globale Ignore-Datei), dann Zeilennummer:Muster, dann der Pfad. Überrascht dich eine spätere Regel, denk an die Vorrangregel: Die letzte passende Regel gewinnt — !important.log nach *.log nimmt genau diese eine Datei wieder auf.

Warum funktioniert gitignore nicht bei bereits committeten Dateien?

Die Datei enttracken, auf der Platte behalten, die Entfernung committen:

# Eine Datei enttracken (die lokale Kopie überlebt — --cached fasst nur den Index an)
git rm --cached .env
git commit -m "stop tracking .env"

# Prüfen, dass die Ignore-Regel jetzt greift
git check-ignore -v .env

Ab diesem Commit gehört der Pfad .gitignore: Änderungen daran tauchen nicht mehr in git status auf, und git add . nimmt ihn nicht wieder auf. Die Datei bleibt aber in der History — war es ein Secret, reicht das Entfernen aus dem letzten Commit nicht. Das Credential zu rotieren ist die einzige echte Lösung; das Umschreiben der History ist die kosmetische (und das Rückgängigmachen des letzten Commits hilft nur, solange der schlechte Commit noch an der Spitze sitzt).

Bei einem Repo voller zuvor committeter Reste — Build-Output, Editor-Rückstände, node_modules, das sich früh einschlich — ist der Bulk-Enttrack ein Zweizeiler:

git rm -r --cached .
git add .
git commit -m "apply .gitignore to tracked files"

Das baut den Index gegen die aktuellen Regeln neu auf: ignorierte Pfade fallen heraus, alles andere wird unverändert neu hinzugefügt. Das Diff sieht dramatisch aus (tausende Löschungen), löscht aber nichts von der Platte. Ist dein Ziel, diese Dateien wirklich zu löschen statt nur zu enttracken, ist das git clean -fdx-Territorium — siehe git remove untracked files, safely.

Git ignoriert Dateien, die es nie gesehen hat. Eine Datei, die bereits im Index liegt, ist immun gegen .gitignore — keine Regel der Welt lässt git sie wieder vergessen.

Warum funktioniert gitignore nicht bei einem Ordner?

Drei ordnerspezifische Fallen:

1. Trailing Slashes betreffen die Absicht, nicht das Matching. build und build/ matchen beide ein Verzeichnis, aber build/ dokumentiert, dass du nur ein Verzeichnis meinst — eine Datei namens build würde davon überleben. Bei der Wieder-Einschließung kippt die Symmetrie allerdings (nächste Falle).

2. Negation kann Dateien in einem ausgeschlossenen Verzeichnis nicht retten. Die Git-Doku ist da eindeutig: „Es ist nicht möglich, eine Datei wieder einzuschließen, wenn ein übergeordnetes Verzeichnis dieser Datei ausgeschlossen ist” (git-scm.com/docs/gitignore). Das ist eine Performance-Entscheidung — git überspringt ausgeschlossene Verzeichnisse komplett, statt sie zu durchlaufen. Das hier funktioniert also nicht:

build/
!build/keep.me        # tote Regel — git schaut nie in build/ hinein

Der Fix: die Inhalte ausschließen, nicht das Verzeichnis:

build/*
!build/keep.me        # funktioniert — build/ selbst bleibt zur Inspektion offen

3. Verschachtelte .gitignore-Dateien gewinnen in ihrem Geltungsbereich. Regeln in subdir/.gitignore überschreiben die Root-Datei für Pfade unterhalb von subdir. Wenn git check-ignore -v eine Ignore-Quelle nennt, mit der du nicht gerechnet hast, liegt es meist daran.

Warum funktioniert gitignore in VS Code nicht?

Fast nie aus VS-Code-Gründen. Die Quellcodeverwaltungs-Ansicht liest denselben Index wie git, das Symptom ist also identisch: Die Datei war bereits committed, und kein IDE-Neustart ändert am Index. Zwei VS-Code-nahe Realitäten sind gut zu wissen:

• Explorer ausgegraut = ignoriert; orange/gelb = getrackt mit Änderungen. Eine Datei, die nach dem Ignorieren noch als geändert erscheint, ist deine Bestätigung, dass sie getrackt ist — führe den git rm --cached-Fix von oben aus.
• Fehlt eine Datei in der Changed-Liste des Explorers, heißt das: Die Regel funktioniert — sie erscheint ja von vornherein nie als ungetrackte Datei. Viele melden „VS Code ignoriert mein gitignore”, während die CLI git status anderer Meinung ist und die SCM-Ansicht veraltet ist; lade das Fenster neu (Cmd/Ctrl+Shift+P → „Reload Window”), bevor du git die Schuld gibst.

.gitignore vs. .git/info/exclude vs. global: was wofür?

Datei	Geltungsbereich	Committed?	Gut für
.gitignore (Repo)	Alle, die klonen	Ja	Build-Output, Dependencies, .env — geteilte Regeln
.git/info/exclude	Nur dein Klon	Nein	Persönlicher Kram: .scratch/, Editor-Rückstände
core.excludesFile (global)	Alle deine Repos	Nein	OS-Müll: .DS_Store, Thumbs.db, *.swp
.gitignore + Negation	Repo	Ja	Ausnahmen wieder einschließen

Die globale Datei ist die eine, die die meisten Entwickler nie setzen — und sollten:

git config --global core.excludesFile ~/.gitignore_global
printf '.DS_Store\nThumbs.db\n*.swp\n' >> ~/.gitignore_global

Hausregel zum Mitnehmen: Nützt eine Regel dem ganzen Team, gehört sie ins Repo; nützt sie nur dir, gehört sie in exclude oder die globale Datei. Persönliche Ignore-Regeln zu committen ist der Grund, warum .gitignore-Dateien 300 Zeilen lang werden und niemand mehr weiß, welche Hälfte noch zählt.

Wie ignoriere ich Änderungen an einer getrackten Datei?

Manchmal willst du eine getrackte Datei (ein Config-Template, eine IDE-Einstellungsdatei), aber die lokalen Änderungen sollen aufhören, in git status aufzutauchen. Zwei Flags an git update-index, von denen keins in einen Team-Workflow gehört:

git update-index --skip-worktree config/local.dev   # lokale Änderungen verstummen
git update-index --no-skip-worktree config/local.dev  # ...und zurück

--skip-worktree ist das vertretbare — es sagt: „Meine lokale Version weicht absichtlich ab.” Sein Vetter --assume-unchanged ist ein Performance-Versprechen („diese Datei ändert sich nicht”), kein Ignore-Mechanismus, und git darf ihn still brechen. Beide Flags scheitern laut beim Pull, wenn upstream die Datei ebenfalls geändert hat — die dauerhaften Antworten sind eine lokale Config per exclude schon bei der Erstellung oder ein Template (config.example), das git trackt und das du kopierst.

Der 30-Sekunden-Gitignore-Health-Check

git check-ignore -v <path>        # welche Regel? (Schweigen = getrackt, keine Regel)
git ls-files --error-unmatch <path>  # ist sie überhaupt getrackt?
git rm --cached <path>            # enttracken, auf der Platte behalten
git commit -m "stop tracking <path>"
git check-ignore -v <path>        # Regel erscheint jetzt

Diagnostizieren, enttracken, verifizieren. Das Muster hinter jedem „gitignore not working”-Report ist dieselbe Datei mit zwei Hüten — auf der einen Seite des Index getrackt, auf der anderen ignoriert — und ein --cached-Flag nimmt den zweiten Hut ab.