Eine .gitignore passend zum Build erstellen
Eine lange Ausschlussliste ist nicht automatisch die bessere. Beginne mit Dateien, die dein Projekt jederzeit neu erzeugen kann: installierten Abhängigkeiten, Build-Ausgaben und Caches. Bei Next.js gehören Node.js und Next.js zusammen; bei Java wählst du Maven oder Gradle passend zum Build.
Die 18 eingebauten Vorlagen sind bewusst kompakte Ausgangspunkte. Sie erkennen dein Repository nicht automatisch und spiegeln nicht die vollständige GitHub-Sammlung. Speichere die geprüften Regeln als .gitignore im Projektstamm oder führe sie mit einer vorhandenen Datei zusammen.
Gemeinsame Konfiguration nicht versehentlich ausschließen
VS Code und JetBrains können Einstellungen enthalten, die das ganze Team benötigt. Die Editor-Vorlagen schließen deshalb nur ausgewählte persönliche Arbeitsdaten aus. Für rein lokale Ausnahmen kannst du .git/info/exclude nutzen.
Auch Lockdateien bleiben verfügbar. Ob eine Anwendung oder Bibliothek sie versionieren soll, entscheidet das Projekt; ein pauschales Muster für alle Lockdateien wäre dafür zu grob.
Drei Ausgangspunkte für dein Projekt
Next.js-Projekt
Node.js-Abhängigkeiten, Next.js-Ausgabe und macOS-Metadaten; Lockdateien bleiben erhalten.
Zurück zum Generator ↑# Mit dem LightNode Gitignore-Generator erstellt
# Diese Grundregeln vor dem Einsatz im Projekt prüfen.
# Node.js
node_modules/
npm-debug.log*
yarn-debug.log*
yarn-error.log*
.pnpm-store/
coverage/
.nyc_output/
# Next.js
.next/
out/
.vercel/
*.tsbuildinfo
# macOS
.DS_Store
._*
.Spotlight-V100/
.Trashes/
Python-Umgebung
Python-Caches und virtuelle Umgebungen mit VS-Code-Verlauf und Linux-Sicherungsdateien.
Zurück zum Generator ↑# Mit dem LightNode Gitignore-Generator erstellt
# Diese Grundregeln vor dem Einsatz im Projekt prüfen.
# Python
__pycache__/
*.py[cod]
.venv/
venv/
.pytest_cache/
.mypy_cache/
.ruff_cache/
.coverage
htmlcov/
*.egg-info/
# VS Code
.history/
*.vsix
# Linux
.Trash-*/
*~
Java mit IntelliJ
Maven und Gradle plus persönliche JetBrains-Daten und Windows-Metadaten. Den ungenutzten Build-Werkzeug-Eintrag abwählen.
Zurück zum Generator ↑# Mit dem LightNode Gitignore-Generator erstellt
# Diese Grundregeln vor dem Einsatz im Projekt prüfen.
# Java / Maven
*.class
target/
# Gradle
.gradle/
build/
# JetBrains
.idea/workspace.xml
.idea/tasks.xml
.idea/shelf/
.idea/httpRequests/
# Windows
Thumbs.db
ehthumbs.db
Desktop.ini
$RECYCLE.BIN/
Fragen zu Gitignore-Regeln
Warum ignoriert Git meine Datei trotzdem nicht?
Bereits verfolgte Dateien bleiben im Index. Prüfe den Status und untersuche die Regel mit git check-ignore -v --no-index path/to/file. Soll die Datei nicht mehr versioniert werden, bereitet git rm --cached -- path/to/file ihre Entfernung aus dem Repository vor; die lokale Datei bleibt. Änderung prüfen und bewusst committen.
Kann ich eine einzelne Logdatei behalten?
Mit /logs/* und danach !/logs/keep.log bleibt diese Datei ausgenommen. Schließe nicht das Elternverzeichnis mit /logs/ aus: In einem ausgeschlossenen Verzeichnis lassen sich Dateien nicht wieder einschließen.
Was geschieht mit eigenen Regeln?
Sie stehen am Ende. Bei gleicher Priorität gilt das letzte passende Muster; deshalb bleiben Reihenfolge und doppelte Regeln erhalten. Eine neue Vorlagenkombination behält deine Eingaben. Alles leeren entfernt Auswahl und Eingaben.
Werden .env-Beispiele ignoriert?
Die optionale Umgebungsvorlage ignoriert .env und .env.*, nimmt aber .env.example und .env.sample aus. Beispiele sollten nur Platzhalter enthalten. Geheimnisse in früheren Commits werden dadurch nicht entfernt.
Verlassen die Regeln meinen Browser?
Die Erstellung verwendet eingebaute Vorlagen ohne Generierungs-API. Das Werkzeug lädt kein Repository hoch, speichert eigene Regeln nicht dauerhaft und schreibt sie nicht in die URL. Kopieren und Download erfolgen auf Knopfdruck.