Was ignorieren, was committen?

Eine gute .gitignore bemisst sich nicht an ihrer Länge, sondern an einem Kriterium. Es gibt nur eines: Kann jemand, der das Repository neu klont, allein aus Quellcode und Konfiguration dasselbe Ergebnis erzeugen? Was sich neu erzeugen lässt, wird ignoriert; was sich nicht neu erzeugen lässt oder das Ergebnis festschreibt, wird committet.

Was ignoriert wird

Art	Beispiele	Grund
Build-Artefakte	`dist/`, `build/`, `target/`, `.o`, `.class`	werden aus dem Quellcode neu erzeugt
Installierte Abhängigkeiten	`node_modules/`, `vendor/` (PHP), `.venv/`	werden über Manifest und Lockfile neu installiert
Caches und Logs	`.cache/`, `.pytest_cache/`, `*.log`, `coverage/`	ändern sich bei jeder Ausführung
Lokale Umgebung und Geheimnisse	`.env`, `.pem`, `local.properties`, `.tfstate`	unterscheiden sich je Person und Umgebung oder dürfen nicht nach außen gelangen
Persönlicher Tool-Zustand	`.DS_Store`, `*.swp`, `.idea/workspace.xml`	haben mit dem Projekt nichts zu tun (globale gitignore empfohlen)

Was committet wird

Lockfiles: package-lock.json, yarn.lock, pnpm-lock.yaml, Cargo.lock, poetry.lock, uv.lock, Gemfile.lock, composer.lock, go.sum, .terraform.lock.hcl. Sie sorgen dafür, dass alle dieselben Versionen installieren. Manche Vorlagen, etwa Angular, ignorieren Lockfiles – prüfen Sie daher das Ergebnis.
Beispielkonfigurationen: .env.example, config.example.yml. Sie zeigen, welche Werte nötig sind, enthalten aber keine echten Geheimnisse.
Wrapper für Build-Tools: gradlew und gradle/wrapper/, mvnw. Prüfen Sie, ob das Wrapper-jar nicht durch *.jar aus der Java-Vorlage ignoriert wird.
Im Team abgestimmte Editoreinstellungen: .editorconfig, .vscode/settings.json, .vscode/extensions.json, .idea/codeStyles/. Gemeinsame Formatierungs- und Lint-Einstellungen erleichtern Reviews.

.gitignore in Unterverzeichnissen

Eine .gitignore muss nicht im Wurzelverzeichnis liegen. Eine .gitignore in einem Unterverzeichnis wirkt relativ zu diesem Verzeichnis und hat Vorrang vor übergeordneten Dateien. Brauchen die Pakete eines Monorepos unterschiedliche Regeln, ist eine eigene Datei im jeweiligen Paketordner leichter zu lesen.

repo/
├── .gitignore          # gemeinsam: .DS_Store, .env, coverage/
├── apps/web/.gitignore # .next/, out/
└── services/api/.gitignore # target/

Leere Verzeichnisse erhalten

git verfolgt nur Dateien und speichert keine leeren Verzeichnisse. Soll wie bei einem Log-Ordner der Ordner existieren, sein Inhalt aber ignoriert werden, legen Sie eine Markierungsdatei hinein und holen sie mit einer Negationsregel zurück.

/log/*
!/log/.keep

Die Namen .keep oder .gitkeep sind keine offizielle git-Funktion, sondern nur eine Konvention. Jeder Name funktioniert. Alternativ können Sie in diesem Ordner eine .gitignore mit folgendem Inhalt ablegen; sie ignoriert alles außer sich selbst.

*
!.gitignore

Beim Zusammenführen von Vorlagen

Üblich ist die Kombination 1–2 Sprachen/Frameworks + Betriebssystem + Editor. Haben Sie Betriebssystem- und Editorregeln global abgelegt, können Sie diese weglassen.
Prüfen Sie die Reihenfolge. Vorlagen mit Negationsregeln (Gradle, VisualStudioCode) gehören hinter Vorlagen mit breiten Regeln (Java, Kotlin).
Duplikate so entfernen, dass die Bedeutung erhalten bleibt. Wiederholte Regeln ändern das Verhalten nicht, erschweren aber das Lesen. Der Generator dieser Website entfernt Duplikate nur, wenn keine Negationsregel dazwischen steht.
Abschnittskommentare stehen lassen. Nur wer Monate später noch weiß, woher eine Regel stammt, kann sie gefahrlos löschen.
Testen. Geben Sie die mit git ls-files ermittelten echten Pfade in den Mustertest ein und prüfen Sie, dass keine unbeabsichtigten Dateien ignoriert werden (z. B. Frontend-Code, der von lib/ aus der Python-Vorlage erfasst wird).

Regeln kurz und konkret halten

Zu breite Regeln wie *.json verschlucken auch Konfigurationsdateien. Grenzen Sie Pfade so weit wie möglich ein (/dist/) und versehen Sie Verzeichnisse mit einem abschließenden Schrägstrich, um sie von gleichnamigen Dateien zu unterscheiden. Ein einzeiliger Kommentar über der Regel mit dem Grund hilft der nächsten Person zu entscheiden, ob sie gelöscht werden darf.