Git Config richtig einrichten: Global, lokal und system-weit

1. Warum die richtige Git-Konfiguration zählt

Die Git-Konfiguration ist die Grundlage für jeden Commit, jeden Merge und jede Zusammenarbeit im Team, wird aber in den meisten Projekten nur einmal oberflächlich mit git config --global user.name eingerichtet und danach nie wieder angefasst. Das Ergebnis: falsche Commit-Autoren in Firmenprojekten, weil die private Identität aus dem globalen Scope durchschlägt, uneinheitliche Merge-Strategien im Team, weil pull.rebase nie gesetzt wurde, und ein Editor, der beim ersten git commit ohne Nachricht unerwartet vi öffnet.

Eine durchdachte Git-Konfiguration löst diese Probleme strukturell, nicht ad hoc. Statt bei jedem neuen Projekt Identität und Verhalten manuell zu setzen, nutzt man die drei Config-Ebenen system, global und local gezielt zusammen mit bedingten Includes, um Arbeits- und Privat-Setups sauber zu trennen. Die folgenden Abschnitte zeigen, wie die Ebenen zusammenspielen, welche Einstellungen den größten Effekt auf den Alltag haben und wie includeIf projektspezifische Overrides automatisiert, ohne dass man beim Wechsel zwischen Repositories daran denken muss.

2. Die drei Config-Ebenen: system, global und local

Git kennt drei Konfigurationsebenen mit klar definierter Präzedenz: --system gilt für alle Benutzer und alle Repositories einer Maschine und liegt üblicherweise unter /etc/gitconfig. --global gilt für einen Benutzer über alle Repositories hinweg und liegt in ~/.gitconfig oder ~/.config/git/config. --local gilt nur für ein einzelnes Repository und liegt in .git/config im jeweiligen Projekt. Bei einem Konflikt gewinnt immer die spezifischere Ebene: local überschreibt global, global überschreibt system.

Diese Präzedenz ist der Kern jedes sinnvollen Git-Config-Setups: Globale Defaults für Editor, Aliases und generelles Workflow-Verhalten gehören in --global, während projektspezifische Ausnahmen wie eine abweichende E-Mail-Adresse für ein Kundenprojekt in --local gesetzt werden. Seit Git 2.x kommt zusätzlich eine vierte, informelle Ebene hinzu: bedingte Includes über includeIf, die abhängig vom Verzeichnis automatisch weitere Config-Dateien einbinden, ohne dass man sie manuell pro Repository pflegen muss. Mit git config --list --show-origin lässt sich jederzeit nachvollziehen, aus welcher Datei ein aktiver Wert tatsächlich stammt.

# System scope: applies to every user on this machine
sudo git config --system core.autocrlf input

# Global scope: applies to the current user across all repositories
git config --global user.name "Jane Developer"
git config --global user.email "jane@example.com"

# Local scope: applies only to the current repository
cd ~/projects/client-shop
git config --local user.email "jane@client-domain.com"

# Precedence check: local wins over global, global wins over system
git config --get user.email          # effective value
git config --list --show-origin      # shows which file each value came from

3. Basis-Konfiguration: user.name, user.email und core.editor

user.name und user.email sind die beiden Werte, die in jedem Commit fest eingebrannt werden und später in git log, git blame und der Contributor-Statistik jedes Hosting-Anbieters erscheinen. Ohne globale Voreinstellung verweigert moderne Git-Versionen den ersten Commit mit einer klaren Fehlermeldung, was zwar unbequem wirkt, aber genau die Fehlcommits mit leerer oder falscher Identität verhindert, die in älteren Git-Versionen häufig unbemerkt blieben. Die E-Mail-Adresse sollte exakt der Adresse entsprechen, die beim Git-Hosting-Anbieter hinterlegt ist, sonst werden Commits nicht dem eigenen Profil zugeordnet.

core.editor bestimmt, welcher Editor bei git commit ohne -m, bei git rebase -i und bei Merge-Konflikten geöffnet wird. Ohne explizite Einstellung fällt Git auf die Umgebungsvariable $EDITOR zurück und landet mangels Alternative oft bei vi, was Entwickler ohne Vim-Erfahrung regelmäßig überrascht. Ein bewusst gesetzter Editor wie VS Code, Sublime Text oder Nano mit dem korrekten Wait-Flag verhindert, dass Git die Kontrolle zurückerhält, bevor der Editor tatsächlich geschlossen wurde.

# ~/.gitconfig - global identity and editor defaults
[user]
    name = Jane Developer
    email = jane@example.com

[core]
    editor = code --wait
    autocrlf = input
    excludesfile = ~/.gitignore_global

[init]
    defaultBranch = main

[color]
    ui = auto

4. Workflow-Einstellungen: pull.rebase und init.defaultBranch

pull.rebase entscheidet, ob git pull intern einen Merge oder ein Rebase gegen den Remote-Branch durchführt. Der Git-Standardwert false erzeugt bei jedem Pull mit lokalen Commits einen zusätzlichen Merge-Commit, der die Historie unnötig verzweigt und in Teams mit häufigen Pulls schnell unübersichtlich wird. Mit git config --global pull.rebase true rebased Git die lokalen Commits stattdessen sauber auf den aktuellen Remote-Stand, was eine lineare, gut lesbare Historie ergibt, solange niemand bereits gepushte Commits umschreibt.

init.defaultBranch legt fest, wie der erste Branch bei git init heißt. Ohne diese Einstellung verwendet Git weiterhin master, während praktisch alle Hosting-Anbieter und CI-Systeme mittlerweile main als Standard erwarten. Wer die Einstellung nicht setzt, produziert bei jedem neuen lokalen Repository einen Branch-Namen, der beim ersten Push manuell umbenannt werden muss. Zwei weitere Einstellungen mit spürbarem Alltagseffekt: fetch.prune = true entfernt veraltete Remote-Tracking-Branches automatisch bei jedem Fetch, und push.default = current pusht immer den aktuellen Branch zu seinem gleichnamigen Remote-Pendant, ohne dass man den Branch-Namen wiederholen muss.

5. Git-Aliases für den produktiven Alltag

Aliases verkürzen häufig getippte Befehle auf wenige Zeichen und reduzieren damit nicht nur Tippaufwand, sondern auch die Fehlerquote bei komplexen Befehlen mit vielen Flags. Ein einfacher Alias wie co für checkout spart bei täglich dutzenden Branch-Wechseln spürbar Zeit. Komplexere Aliases mit dem Präfix ! führen beliebige Shell-Befehle statt reiner Git-Subcommands aus und erlauben so mehrstufige Operationen, etwa das Anzeigen einer kompakten, grafischen Log-Historie mit Farben, Graph-Linien und relativen Zeitangaben in einer einzigen Zeile.

Aliases gehören fast immer in den globalen Scope, weil sie unabhängig vom Projekt nützlich sind. Eine Ausnahme sind projektspezifische Aliases, etwa ein Shortcut für einen firmenspezifischen Deploy-Branch, die dann gezielt in --local gesetzt werden. Wichtig bei der Pflege: Aliases sollten sich an bereits bekannte Shell-Konventionen anlehnen, damit sie ohne Nachschlagen im Muskelgedächtnis bleiben, und in einem Team-Onboarding-Dokument dokumentiert werden, damit neue Kolleginnen und Kollegen dieselben Abkürzungen nutzen können.

# ~/.gitconfig - aliases for everyday commands
[alias]
    co = checkout
    br = branch
    st = status -sb
    cm = commit -m
    amend = commit --amend --no-edit
    unstage = restore --staged
    last = log -1 HEAD --stat

    # Compact graph log with colors and relative dates
    lg = log --graph --pretty=format:'%C(yellow)%h%Creset -%C(auto)%d%Creset %s %C(green)(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit

    # Shell alias: prune local branches already merged into main
    cleanup = "!git branch --merged main | grep -v '\\* main' | xargs -r git branch -d"

6. Per-Projekt-Overrides mit includeIf

Wer beruflich und privat mit unterschiedlichen Git-Identitäten arbeitet, kennt das Problem: Ein Commit im Firmenprojekt landet versehentlich mit der privaten E-Mail-Adresse, weil die globale Konfiguration nicht projektspezifisch überschrieben wurde. Manuelles Setzen von user.email in jedem einzelnen Repository funktioniert, wird aber bei neuen Klonen regelmäßig vergessen. Die robuste Lösung ist includeIf mit der Bedingung gitdir: Sobald ein Repository unterhalb eines bestimmten Verzeichnisses liegt, lädt Git automatisch eine zusätzliche Config-Datei mit den passenden Werten.

Die Struktur dafür: Alle Arbeitsprojekte liegen konsequent unter ~/work/, alle privaten Projekte unter ~/personal/. In ~/.gitconfig verweist ein includeIf "gitdir:~/work/"-Block auf eine separate ~/.gitconfig-work mit Firmen-E-Mail und gegebenenfalls abweichendem Signing-Key. Der Pfad muss zwingend mit einem Slash enden, sonst wird die Bedingung nicht als Verzeichnis-Präfix erkannt. Diese Trennung funktioniert vollautomatisch bei jedem neuen Klon innerhalb der jeweiligen Verzeichnisstruktur, ganz ohne manuellen Zusatzschritt pro Repository.

# ~/.gitconfig - base config with conditional includes
[init]
    defaultBranch = main

# Load work identity for everything under ~/work/
[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

# Load private identity for everything under ~/personal/
[includeIf "gitdir:~/personal/"]
    path = ~/.gitconfig-personal

# ~/.gitconfig-work - only read for repositories inside ~/work/**
[user]
    name = Jane Developer
    email = jane@company.de
    signingkey = ABCD1234EFGH5678
[commit]
    gpgsign = true

7. Credential-Handling und Commit-Signing

Ohne credential.helper fragt Git bei jedem HTTPS-Push erneut nach Benutzername und Passwort beziehungsweise Personal Access Token, was in der Praxis dazu führt, dass Zugangsdaten unverschlüsselt in Shell-History oder Skripten landen. Der eingebaute cache-Helper hält Credentials für eine konfigurierbare Zeitspanne im Arbeitsspeicher, der store-Helper legt sie dauerhaft im Klartext in ~/.git-credentials ab und sollte nur auf vollverschlüsselten, einzeln genutzten Maschinen zum Einsatz kommen. Auf macOS und Windows integrieren osxkeychain und manager die Zugangsdaten direkt in den systemeigenen, verschlüsselten Credential-Store.

Commit-Signing beweist kryptografisch, dass ein Commit tatsächlich von der angegebenen Identität stammt, und wird von GitHub und GitLab mit einem sichtbaren „Verified"-Badge honoriert. commit.gpgsign = true aktiviert die automatische Signatur für jeden Commit, user.signingkey referenziert den zu verwendenden Schlüssel. Seit Git 2.34 unterstützt gpg.format = ssh zusätzlich das Signieren mit bereits vorhandenen SSH-Schlüsseln, was den Umweg über eine separate GPG-Schlüsselverwaltung für viele Teams überflüssig macht.

# Cache credentials in memory for 4 hours instead of asking every push
git config --global credential.helper 'cache --timeout=14400'

# macOS: use the encrypted system keychain instead
git config --global credential.helper osxkeychain

# Sign commits with an existing SSH key (Git 2.34+)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# Verify a signed commit
git log --show-signature -1

8. Diagnose: Herkunft von Config-Werten finden

Wenn ein Commit mit der falschen E-Mail-Adresse erstellt wird, obwohl includeIf korrekt eingerichtet zu sein scheint, ist die erste Anlaufstelle git config --list --show-origin --show-scope. Der Befehl listet jeden aktiven Wert zusammen mit der genauen Datei und der Ebene (system, global, local, worktree) auf, aus der er stammt, und macht damit sofort sichtbar, ob eine lokale Override-Datei einen erwarteten globalen oder bedingten Wert überschreibt. Ohne diesen Befehl bleibt die Fehlersuche bei mehreren Config-Ebenen reines Rätselraten.

Für punktuelle Prüfungen liefert git config --get user.email nur den effektiv aktiven Wert ohne Kontext, während git config --get-all auch mehrfach gesetzte Werte aus verschiedenen Ebenen anzeigt. Zum direkten Bearbeiten öffnet git config --global --edit die globale Datei im konfigurierten Editor, git config --local --edit die lokale Repository-Config. Wer eine Einstellung komplett zurücksetzen will, nutzt git config --unset für einzelne Werte oder git config --remove-section, um einen ganzen Konfigurationsblock zu entfernen, statt die Datei manuell zu editieren und dabei versehentlich die INI-Syntax zu beschädigen.

9. Git-Config-Patterns im direkten Vergleich

Die folgende Übersicht fasst die häufigsten Git-Config-Entscheidungen zusammen und zeigt, welche Variante in der Praxis zu weniger Fehlern und einer saubereren Historie führt.

In der Praxis verstärken sich diese Patterns gegenseitig: Wer includeIf für die Identität nutzt, profitiert erst richtig davon, wenn zusätzlich pull.rebase und init.defaultBranch projektübergreifend konsistent gesetzt sind, weil dann jedes neue Repository ohne manuellen Zusatzschritt sofort den richtigen Workflow verwendet.

10. Zusammenfassung

Eine saubere Git-Konfiguration löst wiederkehrende Probleme strukturell statt ad hoc: Die drei Ebenen system, global und local mit klarer Präzedenz trennen maschinenweite, benutzerweite und projektspezifische Einstellungen. user.name, user.email und core.editor gehören als Basis in den globalen Scope, pull.rebase und init.defaultBranch sorgen für eine lineare Historie und konsistente Branch-Namen über alle neuen Repositories hinweg. Aliases reduzieren Tippaufwand und Fehlerquote bei häufig genutzten Befehlen.

Der größte Hebel für Teams mit gemischten Kontexten liegt in includeIf: Arbeits- und Privat-Identität werden automatisch anhand des Verzeichnispfads geladen, ganz ohne manuellen Zusatzschritt bei jedem neuen Klon. credential.helper und commit.gpgsign runden das Setup sicherheitsseitig ab, indem Zugangsdaten verschlüsselt gespeichert und Commits kryptografisch verifizierbar werden. Mit git config --list --show-origin --show-scope lässt sich jede dieser Einstellungen jederzeit zurückverfolgen, was Debugging bei unerwartetem Verhalten drastisch vereinfacht.

11. FAQ: Git Config richtig einrichten