Viele lokale Dateien gehören nicht in ein Repository. Ein globales gitignore hilft dabei, wiederkehrende Störquellen wie .DS_Store oder .env automatisch aus allen Projekten herauszuhalten.
Warum ein globales gitignore sinnvoll ist
In fast jedem Git-Projekt gibt es Dateien, die nicht ins Repository gehören. Manche davon sind projektspezifisch. Andere entstehen nur durch das eigene Betriebssystem, den Editor oder die lokale Entwicklungsumgebung.
Genau für diese zweite Gruppe eignet sich ein globales gitignore. Es ist keine Alternative zur normalen gitignore im Projekt. Es ergänzt sie um persönliche Regeln, die auf deinem Rechner immer gelten sollen.
Typische Beispiele sind:
.DS_Store
.env
.DS_Store wird unter macOS automatisch vom Finder erzeugt. Die Datei speichert Ordneransichten und andere lokale Finder-Metadaten. Für ein Repository ist sie in der Regel wertlos.
.env enthält häufig lokale Umgebungsvariablen. Darin können API-Keys, Datenbankzugänge oder andere sensible Werte stehen. Solche Dateien sollten nicht versehentlich in ein Repository geraten.
Globales gitignore einrichten
Git kann eine globale Ignore-Datei verwenden. Der folgende Befehl sagt Git, wo diese Datei liegt:
git config --global core.excludesFile ~/.config/git/ignore
Damit setzt du die globale Git-Konfiguration für deinen Nutzer. Ab diesem Zeitpunkt prüft Git zusätzlich die Datei ~/.config/git/ignore, wenn es entscheidet, ob neue Dateien ignoriert werden sollen.
Falls der Ordner noch nicht existiert, kannst du ihn im Terminal anlegen:
mkdir -p ~/.config/git
Danach erstellst oder bearbeitest du die Ignore-Datei:
nano ~/.config/git/ignore
Der Inhalt kann zum Beispiel so aussehen:
.DS_Store
.env
Damit ignoriert Git diese Dateien in allen lokalen Repositories, solange sie noch nicht getrackt werden.
Was gehört in die globale Ignore-Datei?
In eine globale Ignore-Datei gehören Dinge, die mit deinem Rechner oder deinem persönlichen Workflow zu tun haben. Sie sollte nicht zur Ablage projektbezogener Regeln werden.
Projektregeln gehören dagegen weiterhin in die .gitignore des jeweiligen Repositories. Wenn ein Projekt zum Beispiel einen dist-Ordner oder bestimmte Build-Artefakte ignorieren soll, sollte das im Projekt selbst stehen. So sehen auch andere Mitwirkende dieselben Regeln.
Wichtiger Hinweis zu bereits getrackten Dateien
Ein globales gitignore schützt nicht rückwirkend. Wenn eine Datei bereits von Git getrackt wird, ignoriert Git sie nicht einfach, nur weil sie später in einer Ignore-Datei steht.
Das betrifft zum Beispiel eine .env, die versehentlich bereits committed wurde. In diesem Fall muss die Datei aus dem Git-Index entfernt werden:
git rm --cached .env
Danach sollte geprüft werden, ob sensible Werte bereits in der Git-Historie gelandet sind. Ein normales Entfernen aus dem aktuellen Commit reicht dann unter Umständen nicht aus. Bei API-Keys oder Passwörtern ist es meist besser, die betroffenen Zugangsdaten zu rotieren.
Globale Regeln sauber halten
Ein globales gitignore ist praktisch, sollte aber übersichtlich bleiben. Je mehr Regeln dort stehen, desto schwieriger wird es, unerwartetes Git-Verhalten nachzuvollziehen.
Meine Faustregel: Alles, was nur meinen Rechner betrifft, darf global sein. Alles, was ein Projekt für alle Beteiligten betrifft, gehört in die .gitignore des Projekts.
So bleibt die Trennung klar. Das Repository beschreibt das Projekt. Die globale Ignore-Datei beschreibt deinen lokalen Arbeitsplatz.
