.gitignore-Mustersyntax im Überblick

Jede Zeile einer .gitignore ist ein Muster. Die Syntax ähnelt Shell-Globs, doch ihre Bedeutung hängt stark von der Position der Schrägstriche und der Position von ** ab. Die folgenden Angaben stützen sich auf die offizielle git-Dokumentation gitignore(5); die Beispiele wurden mit git 2.50 direkt überprüft.

Leerzeilen, Kommentare, Escaping

• Eine Leerzeile passt auf nichts. Sie dient als Trenner für bessere Lesbarkeit.
• Eine Zeile, die mit # beginnt, ist ein Kommentar. Um eine Datei zu ignorieren, deren Name mit # beginnt, setzen Sie einen Backslash davor, etwa \#.
• Nachgestellte Leerzeichen am Zeilenende werden ignoriert. Brauchen Sie einen Dateinamen, der auf ein Leerzeichen endet, schützen Sie das Leerzeichen mit einem Backslash wie in foo\ . Leerzeichen am Zeilenanfang bleiben Teil des Musters.
• Eine Zeile, die mit ! beginnt, ist ein Negationsmuster. Für eine Datei, deren Name mit ! beginnt, schreiben Sie \!important.txt.

Nachgestellte Leerzeichen sind unsichtbar und daher eine häufige Fehlerquelle. Wenn eine Regel nicht greift, schalten Sie im Editor die Anzeige von Leerzeichen ein. Beachten Sie auch, dass nur Leerzeichen entfernt werden, Tabulatoren dagegen nicht.

Abschließender Schrägstrich: nur Verzeichnisse

Endet ein Muster auf /, passt es nur auf Verzeichnisse. build/ ignoriert das Verzeichnis build samt Inhalt, aber keine Datei namens build. Schreiben Sie dagegen build ohne Schrägstrich, passt es auf Dateien und Verzeichnisse dieses Namens.

Ein Schrägstrich fixiert die Position

Enthält das Muster – ohne den abschließenden Schrägstrich – ein / am Anfang oder in der Mitte, passt es nur auf Pfade relativ zu dem Verzeichnis, in dem die .gitignore liegt. Das nennt man üblicherweise Verankerung (anchoring). Ohne / sucht git in jeder Tiefe unterhalb des Speicherorts der .gitignore nach passenden Namen.

Die dritte Zeile ist besonders verwirrend. logs/debug.log enthält in der Mitte einen Schrägstrich, ist also an der Wurzel verankert und bedeutet dasselbe wie mit vorangestelltem /. Um logs/debug.log in jeder Tiefe zu erfassen, verwenden Sie **/logs/debug.log.

Platzhalter: *, ?, [ ]

• * passt auf jede Zeichenfolge außer / (einschließlich der leeren Zeichenfolge). *.log passt auf app.log und a/b/app.log, logs/*.log dagegen nur auf logs/app.log und nicht auf logs/2026/app.log.
• ? passt auf genau ein Zeichen außer /. file?.txt passt auf file1.txt, aber nicht auf file10.txt.
• [a-z] passt auf ein Zeichen innerhalb des Bereichs, [!a-z] oder [^a-z] auf ein Zeichen außerhalb. *.py[cod] erfasst .pyc, .pyo und .pyd auf einmal. Auch Klammerausdrücke passen nicht auf /.
• POSIX-Zeichenklassen wie [[:digit:]] sind ebenfalls möglich.

Der doppelte Stern **

** hat nur in Verbindung mit einem Schrägstrich eine besondere Bedeutung.

An anderen Stellen, etwa in foo** oder **bar, verhält sich ** wie ein gewöhnliches * und überschreitet keine Schrägstriche. docs/**/*.pdf passt sowohl auf docs/manual.pdf als auch auf docs/a/b/manual.pdf, weil /**/ auch auf null Verzeichnisse passt.

Zusammenfassung an einem kleinen Beispiel

# Build-Ergebnisse (nur das build-Verzeichnis im Wurzelverzeichnis)
/build/

# Logdateien in jeder Tiefe, wichtige Logs bleiben erhalten
*.log
!important.log

# Alle PDFs unterhalb von docs
docs/**/*.pdf

# Datei, deren Name mit # beginnt
\#scratch.md

Diese Tabelle lässt sich genau reproduzieren, indem Sie Regeln und Pfade in den Tab Mustertest des Generators einfügen.

Quellen

• Offizielle gitignore-Dokumentation (git-scm.com)
• GitHub Docs: Ignoring files
• Stand der Prüfung: 2026-09-23 (Beispiele mit git 2.50.1 verifiziert)