.gitignore — Die Datei, die dich vor dem Commit von node_modules rettet

Jeder Entwickler hat es zumindest einmal versehentlich eingegeben node_modules, a .env eine Datei voller API-Schlüssel oder ein 200MB großes Build-Artefakt. Der Stress ist echt. Die Lösung ist langweilig. Und das ganze hätte mit einer einzigen Datei vollkommen vermeidbar sein können .gitignore.

Dieser Leitfaden erklärt, was .gitignore ist, wie es funktioniert, was darin enthalten sein sollte, und einige Fallen, die selbst erfahrene Entwickler treffen

Was ist .gitignore?

.gitignore ist eine einfache Textdatei, die Git sagt, welche Dateien und Verzeichnisse aus der Versionskontrolle auszuschließen. Wenn Git eine Pfadangabe in .gitignoresieht, tut es so, als ob dieser Pfad nicht existiere – er wird nicht gestapelt, nicht eingefügt oder in der git status Ausgabe angezeigt.

Die Datei befindet sich am Ursprung des Repositorys, obwohl Sie auch Projektbezogene .gitignore Dateien in Unterverzeichnissen platzieren können. Regeln in einer Unterverzeichnisdatei gelten nur für das Verzeichnis und seine Kinder.

Warum Sie eine benötigen (kurze Version)

• Sicherheit – hält Geheimnisse, API-Schlüssel und Passwörter aus Ihrer Git-Geschichte
• Repository-Größe – verhindert, dass generierte Dateien und Abhängigkeiten das Repository vergrößern
• Störung reduzieren – verhindert, dass Editor-Konfigurationen und OS-Schrott in jeder Differenz auftauchen
• Team-Integrität – jeder klont ein sauberes Repository und installiert Abhängigkeiten lokal

Wie die Syntax funktioniert

Die Regeln sind einfach, haben jedoch einige nicht offensichtliche Grenzen:

• Leere Zeilen und Zeilen, die mit # beginnen, werden ignoriert (verwenden Sie # für Kommentare)
• Ein Muster ohne Schrägstrich passt auf jede Datei oder Verzeichnis mit diesem Namen an beliebiger Stelle im Repository: *.log ignoriert jede Protokolldatei an jeder Stelle
• Ein abgeschlossener Schrägstrich passt nur auf Verzeichnisse: dist/ ignoriert das Verzeichnis, aber nicht eine Datei mit dem Namen dist
• Ein führender Schrägstrich verankernt das Muster an der Wurzel des Repositorys: /todo.txt ignoriert nur ein todo.txt an der Wurzel
• Doppeltes Sternchen (**) passt über Verzeichniskonstanten: **/logs passt logs/ irgendwo im Baum
• Ein Ausrufezeichen (!) negiert ein Muster und inkludiert eine Datei, die von einer vorherigen Regel ausgenommen wurde

Ein minimales Beispiel

# Dependencies
node_modules/

# Environment files
.env
.env.local
.env.*.local

# Build output
dist/
build/

# Editor noise
.vscode/
.idea/
*.swp

# OS files
.DS_Store
Thumbs.db

# Logs
*.log
npm-debug.log*

Die häufigsten Einträge (und warum sie wichtig sind)

node_modules/

Dies ist das große Thema. Ein typisches Node.js-Projekt hat Tausende von Dateien in node_modules/ – oft hunderte Megabytes. Keine davon gehört in die Versionskontrolle. Jeder, der Ihr Repository klonen möchte, führt npm install und erneuert es lokal aus package.json. Ignorieren Sie es immer.

.env und geheime Dateien

Umgebungsdateien enthalten Datenbankpasswörter, API-Schlüssel und Diensttokens. Ein eingegebenes .env ist ein Sicherheitsvorfall, der sich ereignet kann – GitHub scannt nach enthüllten Geheimnissen, aber auch Bot-Systeme. Ignorieren Sie die Datei und committen Sie eine .env.example mit Platzhalterwerten, damit die Teammitglieder wissen, welche Variablen zu setzen sind.

dist/ und build/

Kompierte oder gebundene Ausgaben werden aus der Quelle abgeleitet. Ihr CI-Pipeline erneuert sie bei jeder Bereitstellung. Das Committing von Build-Artefakten führt zu Merge-Konflikten und falschen Differenzen, die echte Codeänderungen verdecken.

Editor- und OS-Dateien

.DS_Store (macOS), Thumbs.db (Windows), .idea/ (JetBrains), .vscode/ (VS Code-Einstellungen) – diese sind persönliche Arbeitsumgebungsdateien. Das Committing dieser Dateien erzwingt Ihre Einstellungen für jeden anderen Mitentwickler. Verwenden Sie eine globale ~/.gitignore_global für maschinenbezogene Störungen, damit Sie diese nicht in jedes Projekt hinzufügen müssen.

Globale .gitignore: Einmal einstellen, vergessen

Sie können eine globale Ignorierdatei konfigurieren, die auf jedes Repository auf Ihrem Gerät gilt:

git config --global core.excludesfile ~/.gitignore_global

Platzieren Sie Editor-Dateien, OS-Schrott und persönliche Tools dort. Reservieren Sie die Projekt- .gitignore für Dinge, die das gesamte Team ignorieren will – wie node_modules/ oder dist/.

Der „bereits verfolgte“-Falle

Hier werden Entwickler oft geschlagen: .gitignore verhindert nur unverfolgte Dateien, die hinzugefügt werden. Wenn eine Datei bereits in Ihrer Git-Geschichte ist, hat das Hinzufügen zu .gitignore keine Wirkung. Git verfolgt sie weiterhin und wird Änderungen daran weiterhin committen.

Um eine bereits eingegebene Datei aus der Verfolgung zu entfernen:

# Remove the file from git tracking without deleting it locally
git rm --cached path/to/file

# Or remove a whole directory
git rm -r --cached node_modules/

# Then commit the removal
git commit -m "Stop tracking node_modules"

Danach bleibt die Datei auf der Festplatte, Git ignoriert sie jedoch ab jetzt.

Negationsregeln: Dateien erneut einbeziehen

Manchmal möchte man ein Verzeichnis ignorieren, außer für eine bestimmte Datei – zum Beispiel, ignorieren config/ aber behalten config/defaults.json in der Version:

config/
!config/defaults.json

Ein Haken: Negation kann eine Datei nicht außerhalb eines ignorierten Verzeichnisses wieder einbeziehen. Git beendet die Abstieg in ignorierte Verzeichnisse, sodass die ! Regel nie die Gelegenheit bekommt, zu funktionieren. Sie müssen die Inhalte ignorieren, anstatt das Verzeichnis selbst:

# Wrong — Git never sees defaults.json inside an ignored directory
config/
!config/defaults.json

# Right — ignore everything in config/ except defaults.json
config/*
!config/defaults.json

Eine .gitignore generieren für Ihre Technologie

Sie müssen nicht von Grund auf schreiben. gitignore.io (auch unter gitignore.io) lässt Sie Ihre Sprache, Framework und Editor auswählen und generiert ein umfassendes Ignorier-Datei sofort. GitHub bietet ebenfalls offizielle Vorlagen in seinem github/gitignore Repository – diese sind gut gepflegt und decken Hunderte von Umgebungen ab.

Für die meisten Webprojekte ist ein solider Ausgangspunkt eine Kombination aus Vorlagen für Ihre Sprache (Node, Python, PHP usw.), Ihren Editor (VS Code, JetBrains) und Ihre Plattform (macOS, Windows).

Überprüfen, was Git ignoriert

Zwei Befehle helfen, eine unerwartete Ignorierregel zu debuggen:

# See which files are being ignored in the current directory
git status --ignored

# Find out exactly which rule is causing a file to be ignored
git check-ignore -v path/to/file

git check-ignore -v ist besonders nützlich, wenn eine Regel nicht das erwartete Verhalten zeigt – es zeigt die Datei, die Zeile und das Muster, das verantwortlich ist.

Schnelle Referenz: Muster-Cheat Sheet

Muster	Was es ignoriert
*.log	Alle .log Dateien überall
/debug.log	Nur debug.log an der Wurzel
logs/	Jedes Verzeichnis mit dem Namen logs
**/logs	logs Verzeichnis an jeder Tiefe
!important.log	Wieder einbeziehen important.log auch wenn *.log es passt
doc/*.txt	.txt Dateien direkt im Verzeichnis doc/ (nicht Unterverzeichnisse)
doc/**/*.txt	.txt Dateien überall unter doc/

Das könnte Ihnen auch gefallen