Erstellen Sie eine .gitignore aus 61 Vorlagen für Sprachen, Frameworks, Editoren und Systeme
Läuft in Ihrem Browser. Nichts, was Sie eingeben, wird irgendwohin gesendet. Geprüft am 16. Oktober 2026.Eine .gitignore-Datei listet die Dateien auf, die git nicht verfolgen soll, ein Muster pro Zeile. Wählen Sie die Vorlagen für Ihren Stack, etwa Node.js, macOS und VS Code, aus 61 offiziellen github/gitignore-Vorlagen; sie werden zu einer Datei zusammengeführt, die Sie kopieren oder herunterladen, und jeder Pfad lässt sich vor dem Commit gegen die Regeln testen.
Diese Seite wurde maschinell aus dem englischen Original übersetzt. Die Übersetzung wurde noch von keinem Menschen geprüft; maßgeblich ist die englische Fassung. Englisches Original lesen
Tippen Sie die Vorlagen für Ihr Projekt an, etwa Node.js, macOS und VS Code, oder suchen Sie eine nach Namen.
Fügen Sie eigene Zeilen wie *.pem oder scratch/ im Feld Eigene Regeln hinzu.
Geben Sie unter Pfade testen einige Pfade ein, um zu sehen, welche git ignoriert und welche Regel entscheidet.
Klicken Sie auf Kopieren oder Herunterladen und speichern Sie die Datei als .gitignore im obersten Ordner des Repositorys.
Jedes neue Repository braucht vor dem ersten Commit eine .gitignore, sonst landen Build-Ausgaben, Abhängigkeiten und Editor-Einstellungen in der Historie. GitHub veröffentlicht eine Vorlage pro Sprache, Framework, Editor und Betriebssystem; diese Seite enthält 61 davon, auf einem festen Commit, und führt die angetippten zu einer einzigen Datei zusammen.
Zusammenführen ohne Überraschungen. Vorlagen überschneiden sich: Node.js, Next.js und NestJS ignorieren alle Logs. Eine wiederholte Zeile wird nur entfernt, wenn keine !-Regel zwischen den beiden Kopien steht, sodass die zusammengeführte Datei genau das ignoriert, was die Vorlagen nacheinander ignorieren. Die Seite zeigt an, wie viele Zeilen entfernt wurden.
Pfade testen. Geben Sie unter Pfade testen Pfade ein, einen pro Zeile, mit einem Schrägstrich am Ende eines Ordners. Jeder wird als ignoriert oder behalten markiert, mit der Zeilennummer und der Regel, die entschieden hat. Der Abgleich folgt den Regeln von git selbst:
| Muster | Trifft zu auf | Trifft nicht zu auf |
|---|---|---|
*.log |
debug.log, logs/app.log |
log.txt |
build/ |
den Ordner build in jeder Tiefe |
eine Datei namens build |
/dist |
dist nur auf oberster Ebene |
src/dist |
doc/*.txt |
doc/a.txt |
doc/sub/a.txt |
**/secrets/** |
api/secrets/key.pem |
secrets selbst |
!keep.log |
holt keep.log zurück |
eine Datei in einem ignorierten Ordner |
Eine Datei in einem ignorierten Ordner bleibt ignoriert. Git schaut nicht in einen ignorierten Ordner hinein, daher hat !secret/ok.txt nach secret/ keine Wirkung. Schreiben Sie stattdessen secret/*, dann funktioniert die !-Zeile.
Bereits verfolgte Dateien. Eine .gitignore wirkt nur auf nicht verfolgte Dateien. Wurde eine Datei schon committet, entfernen Sie sie mit git rm --cached aus dem Index und committen Sie; die Datei bleibt auf Ihrer Festplatte.
Der Pfad-Tester wurde mit git check-ignore an mehr als 1.000 Pfaden geprüft, mit handgeschriebenen Regelsätzen und echten Vorlagen. Alles läuft in Ihrem Browser; nichts, was Sie eingeben, wird irgendwohin gesendet.
Speichern Sie sie als .gitignore, mit dem führenden Punkt und ohne Endung, im obersten Ordner des Repositorys, neben dem .git-Ordner. Muster mit einem Schrägstrich am Anfang oder in der Mitte werden von diesem Ordner aus gelesen. Eine .gitignore in einem Unterordner funktioniert ebenfalls und gilt nur darunter.
Eine .gitignore wirkt nur auf Dateien, die git noch nicht verfolgt. Sobald eine Datei committet wurde, verfolgt git sie weiter. Führen Sie git rm --cached gefolgt vom Pfad aus, committen Sie, und ab dann greift die Regel. Die Datei bleibt auf Ihrer Festplatte; nur ihre Kopie im Index verschwindet.
Ignorieren Sie den Inhalt des Ordners statt des Ordners selbst: Schreiben Sie logs/* und dann !logs/keep.txt. Schreiben Sie stattdessen logs/, überspringt git den ganzen Ordner, ohne hineinzuschauen, und die !-Zeile kann die Datei nie zurückholen. Das Feld Pfade testen zeigt, welcher Fall vorliegt.
Ein Schrägstrich am Ende beschränkt das Muster auf Ordner, sodass build/ einen Ordner namens build ignoriert, aber keine Datei. Ein Schrägstrich am Anfang oder in der Mitte bindet das Muster an den Ordner der .gitignore, sodass /dist nur das oberste dist ignoriert. Ohne Schrägstrich trifft das Muster in jeder Tiefe zu.
Ja. Die 61 Texte stammen unverändert aus dem Repository github/gitignore auf einem festen Commit, der Sammlung, die GitHub beim Anlegen eines Repositorys verwendet, veröffentlicht unter der Lizenz CC0. Jeder Block im Ergebnis trägt den Namen der Vorlage als Überschrift, sodass Sie sehen, woher eine Regel stammt.
Ja, wie git unter Linux und in den meisten CI-Systemen, daher trifft Build/ nicht auf einen Ordner namens build zu. Unter Windows und macOS setzt git core.ignorecase meist auf true und ignoriert die Schreibweise, sodass ein Muster lokal zutreffen kann, auf dem Build-Server aber nicht. Schreiben Sie Muster in der exakten Schreibweise der Dateien.
Sätze und Regeln ändern sich; prüfen Sie die Quelle, bevor Sie sich auf eine Zahl verlassen.
Kommen Sie nicht weiter? Fragen Sie zu .gitignore-Generator und jeder, der es weiß, kann antworten. Kein Konto nötig.