Einführung

Eine .gitignore-Datei listet Muster auf, die Git als untracked behandeln und niemals zum Hinzufügen vorschlagen soll. Sie hält Build-Artefakte, Geheimnisse, OS-Metadaten und Editor-Hilfsdateien aus Ihrem Repository fern.

Mustersyntax

• name: Passt auf Dateien oder Verzeichnisse namens name in beliebiger Tiefe.
• /name: Passt nur auf Repository-Wurzelebene.
• name/: Passt nur auf Verzeichnisse.
• *.log: Glob; passt auf jede .log-Datei.
• **/build: Passt auf build in beliebiger Tiefe.
• !important.log: Schließt einen zuvor ignorierten Pfad wieder ein.
• # am Zeilenanfang ist ein Kommentar.

Ein realistisches Beispiel

# .gitignore
# Build-Output
/dist/
/build/
*.o
*.pyc

# Abhängigkeiten
/node_modules/
/vendor/

# Editoren
.idea/
.vscode/
*.swp

# OS
.DS_Store
Thumbs.db

# Geheimnisse
.env
*.pem

Mehrere .gitignore-Dateien

Sie können eine .gitignore auf jeder Ebene platzieren. Muster sind relativ zum Verzeichnis der Datei, und tiefer liegende Dateien überschreiben flachere. Es gibt auch eine globale Ignore-Datei für persönliche Vorlieben:

git config --global core.excludesFile ~/.gitignore_global

Verwenden Sie diese für Editor-Swap-Dateien und OS-Müll, nicht für projektspezifische Pfade.

Bereits verfolgte Dateien

Einen Pfad zu .gitignore hinzuzufügen, entfernt ihn nicht aus dem Repository. So beenden Sie das Verfolgen einer Datei, während Sie sie auf der Festplatte behalten:

git rm --cached secrets.env
git commit -m "Stop tracking secrets.env"

Ignorierregeln debuggen

Warum ignoriert (oder ignoriert nicht) Git einen Pfad? Fragen Sie:

git check-ignore -v path/to/file

Die Ausgabe nennt Datei und Zeile, die zugetroffen haben.

Auswertungsreihenfolge

Git wertet Ignore-Regeln aus mehreren Quellen in folgender Reihenfolge aus: Befehlszeilenargumente, dann verzeichnisspezifische .gitignore-Dateien (am tiefsten zuerst), dann $GIT_DIR/info/exclude, und schließlich die globale core.excludesFile. Spätere (spezifischere) Regeln überschreiben frühere, und eine Negation (!pattern) schließt einen Pfad nur dann wieder ein, wenn dessen Elternverzeichnis nicht selbst ausgeschlossen ist. Diese letzte Regel stolpert viele Nutzer:

# Falsch: kann eine Datei in einem ignorierten Verzeichnis nicht wieder einschließen
/build/
!/build/keep.log

# Richtig: Inhalt ignorieren, aber das Verzeichnis behalten
/build/*
!/build/keep.log

Pro-Repo- und globale Excludes

Zwei zusätzliche Ignore-Mechanismen ergänzen .gitignore. Die pro-Repo, untracked Datei .git/info/exclude gilt nur für Ihren Klon (gut für IDE-Dateien, die Sie nicht für das ganze Team in .gitignore committen wollen). Die globale core.excludesFile gilt für alle Ihre Repositories:

echo ".idea/" >> .git/info/exclude
git config --global core.excludesFile ~/.gitignore_global
echo ".DS_Store" >> ~/.gitignore_global

Verwenden Sie diese für persönliche Vorlieben; reservieren Sie die committete .gitignore für teamweite Regeln.

Häufige Fehler

Das Hinzufügen von secrets.env zu .gitignore, nachdem es bereits committet wurde, und davon ausgehen, dass das Geheimnis weg ist. Es ist immer noch in der Historie; rotieren Sie das Geheimnis und ziehen Sie git filter-repo in Betracht, um es zu entfernen. Eine weitere Falle: Ein Verzeichnis mit build ignorieren, wenn Sie /build meinten, und so versehentlich eine Datei namens build tief im Baum unterdrücken. Schließlich: Das Committen von .gitignore selbst ist essentiell; ohne sie muss jeder Mitarbeiter eigene Ignore-Regeln erfinden. .gitignore gehört in das Repository, nicht außerhalb.