block .gitignore Generator star

So funktioniert es

Kreuzen Sie an, was auf Ihr Projekt zutrifft — eine Sprache oder Laufzeitumgebung wie Node.js, Python oder Java, ein Betriebssystem wie macOS, Windows oder Linux, einen Editor wie VS Code oder IntelliJ/JetBrains, dazu die eigenen Restdateien von Git und einen Block für .env und Geheimnisse. Jedes Kontrollkästchen fügt eine kleine, etablierte Sammlung von Ignore-Mustern hinzu, die aus den tatsächlich in der Community üblichen Konventionen stammen — node_modules/ für Node, __pycache__/ und .venv/ für Python, *.class und target/ für Java, .DS_Store für macOS, Thumbs.db für Windows und so weiter. Je mehr Kästchen Sie ankreuzen, desto mehr führt das Tool alles in einer Liste zusammen, entfernt exakte Duplikate und zeigt das Ergebnis live in einem Textfeld an, das Sie kopieren oder direkt als Datei namens .gitignore herunterladen können.

Der Grund, Kategorien zu kombinieren statt eine Datei von Grund auf neu zu schreiben, liegt darin, dass die meisten echten Projekte gleich mehrere davon betreffen: Eine Node.js-API, die auf einem Mac in VS Code entwickelt wird, braucht den Node-Block für Build-Artefakte, den macOS-Block, damit .DS_Store nie in einen Pull Request rutscht, und den VS-Code-Block, damit Ihre persönlichen Editor-Einstellungen nicht die eines Teamkollegen überschreiben. Alle drei anzukreuzen und einmal herunterzuladen ist schneller und weniger fehleranfällig, als Muster aus dem Gedächtnis zusammenzustellen oder Fragmente aus alten Projekten zusammenzukopieren.

Gut zu wissen

Eine .gitignore-Datei wirkt sich nur auf Dateien aus, die Git noch nicht kennt — sie sagt Git, welche nicht verfolgten (untracked) Dateien bei git status, git add . und künftigen Commits ausgelassen werden sollen. Sie hat keine Wirkung auf Dateien, die bereits verfolgt werden (mindestens einmal committet wurden). Das ist der mit Abstand häufigste Missverständnispunkt: .env zur .gitignore hinzuzufügen, nachdem sie bereits committet wurde, entfernt sie weder aus dem Repository noch hindert es Git daran, weitere Änderungen daran zu verfolgen. Um eine Datei tatsächlich aus der Versionskontrolle zu nehmen, müssen Sie zunächst git rm --cached <datei> ausführen (dies entfernt sie aus dem Git-Index, lässt sie aber auf der Festplatte), diese Entfernung committen — erst dann greift die passende .gitignore-Regel für die Zukunft.

Die meisten hier angebotenen Muster gehen auf GitHubs offizielles github/gitignore-Repository zurück, die meistreferenzierte Quelle für sprach- und toolspezifische Vorlagen und dieselbe Sammlung, die GitHub selbst anbietet, wenn Sie über die Weboberfläche ein neues Repository erstellen. Abhängigkeitsordner wie node_modules/ und Build-Ausgaben wie dist/ oder target/ aus der Versionskontrolle herauszuhalten, ist aus Größengründen wichtig — diese Ordner können Ihren eigentlichen Quellcode leicht um ein Vielfaches übertreffen und lassen sich problemlos aus einer Lockfile oder einem Build-Skript neu erzeugen —, während Dateien wie .env, *.pem und *.key draußen zu halten aus Sicherheitsgründen wichtig ist: Ein Geheimnis in die Git-Historie zu committen macht es faktisch für immer öffentlich, da das Löschen aus dem letzten Commit es nicht aus früheren Commits entfernt, ohne die Historie vollständig neu zu schreiben.