.gitignore-Generator

Was ist eine .gitignore-Datei?

Eine .gitignore-Datei sagt Git, welche Pfade aus der Versionskontrolle herausgehalten werden sollen. Sie liegt im Stammverzeichnis deines Repositorys und wird selbst eingecheckt — somit greifen in jedem Klon dieselben Regeln. Ohne sie landen kompilierte Binärdateien, Abhängigkeitsordner, IDE-Caches, Logdateien und (am schlimmsten) Geheimnisse wie .env-Dateien in der Versionierung. Sind diese erst einmal in der Historie, bleiben sie unter Umständen für immer durchsuchbar — selbst nach einem Force-Push. Deshalb ist es wichtiger, die .gitignore gleich zu Projektbeginn richtig aufzusetzen, als viele denken. Dieser Generator führt bewährte Muster für die Sprachen, Frameworks, Betriebssysteme und Editoren zusammen, die du tatsächlich verwendest, und entfernt doppelte Header, damit die Datei lesbar bleibt. Er gibt ausschließlich Pfadmuster aus — niemals Quellcode — und kann daher gefahrlos in ein öffentliches Repo übernommen werden. Wenn dein Projekt Backend, Frontend, zwei Betriebssysteme und drei Editoren im Team mischt, hak einfach alles ab: Das Ergebnis ist eine einzige Datei, kein Ordner, und Git behandelt jede Zeile als additiv. Du kannst das Ergebnis als Ausgangspunkt einfügen und von dort aus anpassen.

So funktioniert es

1. Vorlagen auswählen

Klicke auf einen beliebigen Chip aus den Listen für Sprachen, Betriebssysteme oder Editoren. Nutze das Filterfeld oben, wenn die Liste lang ist — es durchsucht sowohl die Bezeichnung als auch den internen Schlüssel.

2. Ausgabe prüfen

Jede Vorlage erhält ihren eigenen kommentierten Abschnitts-Header (# === Node.js ===), damit du auf einen Blick erkennst, woher welche Regeln stammen. Die Reihenfolge entspricht der Reihenfolge deiner Klicks.

3. Kopieren oder herunterladen

Kopiere alles in die Zwischenablage oder klicke auf Herunterladen, um die Datei direkt als .gitignore zu speichern. Lege sie vor deinem ersten Commit im Stammverzeichnis deines Repos ab.

4. Bei Bedarf anpassen

Betrachte die Ausgabe als Ausgangspunkt. Ergänze projektspezifische Pfade (Uploads, generierte Docs, Scratch-Dateien) am Ende und entferne jede Regel, die nicht zu deinem Setup passt.

Was die einzelnen Regeln bewirken

Muster in .gitignore folgen einfachen Regeln. Ein wörtlicher Pfad wie node_modules/ ignoriert dieses Verzeichnis überall, wo es vorkommt. Ein führender Schrägstrich (/dist) verankert das Muster im Repo-Stammverzeichnis. Glob-Zeichen funktionieren wie erwartet: *.log trifft Dateien per Endung, **/cache ist rekursiv und Klammern wie *.[oa] matchen einen Zeichensatz. Ein vorangestelltes ! negiert eine vorherige Regel — so behält Unity beispielsweise .meta-Dateien, auch wenn deren Zielobjekt ignoriert wird. Zeilen, die mit # beginnen, sind Kommentare. Ein abschließender Schrägstrich bedeutet „nur Verzeichnis“. Bereits getrackte Dateien sind nicht betroffen — um eine Datei nach dem Eintrag in .gitignore aus dem Tracking zu entfernen, führe git rm --cached pfad aus.

Wann was hinzufügen

Wähle Vorlagen für Sprache und Framework für Build-Artefakte und Abhängigkeitsordner (node_modules/, vendor/, target/). Füge die Betriebssystem-Vorlage für die Systeme hinzu, die dein Team verwendet — macOS verteilt überall .DS_Store und Windows streut Thumbs.db. Ergänze eine Editor-Vorlage für die IDE, auf die sich das Team geeinigt hat; arbeitet das Team gemischt, füge alle hinzu. Als Faustregel gilt: mindestens ein Stack + ein Betriebssystem + ein Editor für jedes neue Repo. Vermeide es, Lock-Dateien (package-lock.json, composer.lock, Gemfile.lock) zu ignorieren — diese sollten für reproduzierbare Builds eingecheckt werden.

Häufig gestellte Fragen