.gitignore Syntax und Regeln für Muster
Detaillierte Übersicht über Formatierungsregeln, Glob-Wildcards, voran- und nachgestellte Schrägstriche sowie die Fallstricke bei Ordner-Negierungen.
Jede Zeile in einer .gitignore-Datei repräsentiert ein eigenständiges Ausschlussmuster nach drei Basisregeln:
- Leerzeilen werden ignoriert und dienen als visuelle Trenner zur besseren Lesbarkeit.
- Zeilen, die mit # beginnen, sind Kommentare und beeinflussen die Versionsverwaltung nicht.
- Nachgestellte Leerzeichen werden ignoriert, es sei denn, sie werden mit einem Backslash (\ ) maskiert.
# Ignore compiled Python bytecode
__pycache__/
*.py[cod]
# Ignore local secret configurations
.env
.env.localGit unterstützt die gewohnten Unix-Shell-Globbing-Muster innerhalb einer einzelnen Ordnerebene:
- * (Sternchen): Passt auf null oder mehr Zeichen innerhalb eines Pfadsegments. *.log matcht error.log, aber nicht ordner/error.log.
- ? (Fragezeichen): Passt exakt auf ein einzelnes Zeichen. test?.js matcht test1.js, aber nicht test12.js.
- [abc] (Zeichenbereich): Passt auf ein beliebiges Zeichen innerhalb der Klammern. *.[oa] matcht .o- oder .a-Dateien.
Die Position von Schrägstrichen (/) steuert grundlegend, wie Git das Muster interpretiert:
- Abschließender Schrägstrich (logs/): Beschränkt das Muster ausschließlich auf Verzeichnisse. logs/ wird ignoriert, eine Datei namens logs jedoch nicht.
- Führender Schrägstrich (/config.json): Verankert das Muster am Speicherort der .gitignore-Datei. /config.json wird ignoriert, /sub/config.json bleibt getrackt.
- Mittlerer Schrägstrich (docs/*.html): Verankert das Muster ebenfalls relativ zum Verzeichnis der .gitignore-Datei.
Zwei aufeinanderfolgende Sternchen matchen über mehrere Verzeichnisebenen hinweg:
- **/cache: Matcht jeden Ordner oder jede Datei namens cache an beliebiger Stelle im Repository (cache, src/cache, a/b/c/cache).
- logs/**: Matcht sämtliche Dateien und Unterordner innerhalb von logs/, unabhängig von der Verzeichnistiefe.
- a/**/b: Matcht a/b, a/x/b, a/x/y/b und so weiter.
Ein Ausrufezeichen (!) negiert ein vorheriges Muster und schließt eine Datei wieder in das Tracking ein.
Aus Performancegründen durchsucht Git ignorierte Ordner überhaupt nicht. Wenn build/ ignoriert wird, wird Git eine Datei darin NIE durch !build/wichtig.txt wieder aufnehmen.
Um eine Datei innerhalb eines ignorierten Verzeichnisses einzuschließen, müssen Sie den Inhalt des Ordners ignorieren anstatt des Ordners selbst:
# INCORRECT: Will NOT work because parent directory is skipped
node_modules/
!node_modules/my-local-package
# CORRECT: Ignore contents of directory, then whitelist the specific target
node_modules/*
!node_modules/my-local-package/Wenn Sie überprüfen möchten, welche .gitignore-Regel auf eine Datei zutrifft, nutzen Sie das Git-Diagnosekommando mit -v:
# Shows the exact .gitignore file and line number responsible
git check-ignore -v src/temp/debug.logHäufig gestellte Fragen
Praktische Antworten auf häufige Entwicklerfragen zu .gitignore-Regeln, Caching und Repository-Konfiguration.
Was ist der Unterschied zwischen * und ** in .gitignore?
Ein einzelnes Sternchen (*) matcht Zeichen innerhalb einer einzelnen Ordnerebene. Zwei Sternchen (**) matchen über beliebig tief verschachtelte Verzeichnisse hinweg.
Warum funktioniert !ordner/datei.txt nicht, wenn ordner/ ignoriert wird?
Git durchsucht ignorierte Verzeichnisse nicht. Ignorieren Sie mit 'ordner/*' den Ordnerinhalt und definieren Sie anschließend die Ausnahme.
Wie finde ich heraus, welche Regel eine Datei ignoriert?
Führen Sie 'git check-ignore -v <pfad>' aus. Git gibt die genaue Datei und Zeilennummer des zutreffenden Musters aus.
.gitignore Anleitungen & Referenz
Bereits getrackte Dateien in Git ignorieren
Die definitive Lösung für ein bekanntes Problem: Wie man sensible oder generierte Dateien nachträglich aus dem Git-Index entfernt.
Verzeichnisse in Git richtig ignorieren
Klare Anleitung für Verzeichnisregeln: Bedeutung des abschließenden Schrägstrichs, stammrelative Pfade, Unterordner und leere Verzeichnisse.
.gitignore Beispiele für moderne Tech-Stacks
Praktische, kuratierte Ausschlussregeln für gängige Programmiersprachen, Backend-Frameworks, Spieleentwicklung und Container-Setups.