Andere git Nutzer für GitHub, Azure DevOps, GitLab etc. verwenden

Wenn man auf GitHub unter einem persönlichen Alias committen möchte, in Azure DevOps jedoch mit der Unternehmens‑Identität, empfiehlt sich eine saubere Trennung der Git‑Identitäten anhand des Projektpfads.

Die folgende Lösung nutzt Conditional Includes in Git und funktioniert zuverlässig unter Git for Windows.

Voraussetzungen

Git for Windows ≥ 2.40
Windows‑Umgebung (Beispiele beziehen sich auf C:\‑Pfade)

Version prüfen:

git --version

Globale Git‑Konfiguration

Die globale Git‑Konfiguration befindet sich unter:

%USERPROFILE%\.gitconfig

Hier wird die Standard‑Identität hinterlegt, z. B. die Unternehmens‑Identität für Azure DevOps:

[user]
    name = Kirsten Kluge
    email = Kirsten.Kluge@awesomecompany.com
    useConfigOnly = true

useConfigOnly = true stellt sicher, dass Git keine impliziten Fallback‑Identitäten verwendet und verhindert versehentliche Commits mit falschem Absender.

Pfadbasierte Identität für GitHub

Alle GitHub‑Projekte liegen unter einem gemeinsamen Ordner:

C:/Arbeit/work/github/

Am Ende der globalen .gitconfig wird nun ein Conditional Include ergänzt:

[includeIf "gitdir:**/work/github/**"]
    path = C:/Arbeit/work/github/.gitconfig

das Pattern ist bewusst generisch gewählt
neue GitHub‑Projekte erfordern keine Anpassung der globalen Config
der Include greift nur für Unterordner, nicht für den Ordner selbst

Lokale GitHub‑Konfiguration

Im GitHub‑Root liegt eine eigene .gitconfig:

C:/Arbeit/work/github/.gitconfig

Inhalt:

[user]
    name = Kirsten Kluge
    email = Kirsten.Kluge@githubemail.com

Diese Identität gilt automatisch für alle Git‑Repositories unterhalb dieses Pfads.

Überprüfung der aktiven Identität

Innerhalb eines GitHub‑Repositories:

C:\Arbeit\work\github\meinProjekt> git config user.name
Kirsten Kluge

C:\Arbeit\work\github\meinProjekt> git config user.email
Kirsten.Kluge@githubemail.com

Außerhalb des GitHub‑Pfads:

C:\Arbeit\work> git config user.name
Kirsten Kluge

C:\Arbeit\work> git config user.email
Kirsten.Kluge@awesomecompany.com

Mehrere Kunden unter einem gemeinsamen `work`‑Ordner

Neben GitHub‑Projekten existieren häufig mehrere Kundenprojekte unter einem gemeinsamen Arbeitsverzeichnis:

C:/Arbeit/work/
├── .gitconfig
├── github/
│   ├── .gitconfig
│   └── projekt-x/
│       └── .git/
├── kunde-a/
│   ├── .gitconfig
│   └── projekt1/
│       └── .git/
├── kunde-b/
│   ├── .gitconfig
│   └── projekt2/
│       └── .git/
└── kunde-c/
    └── projekt3/
        └── .git/

work ist der feste Root‑Ordner
jeder Kundenordner kann eine eigene .gitconfig enthalten
der Dateiname ist überall bewusst einheitlich

Globale Einbindung des `work`‑Ordners

In der globalen %USERPROFILE%\.gitconfig wird einmalig festgelegt, dass für alle Repositories unterhalb von work eine zusätzliche Konfiguration geladen wird:

[includeIf "gitdir/i:**/work/**"]
    path = C:/Arbeit/work/.gitconfig

Diese Regel muss nie wieder angepasst werden, auch wenn neue Kunden hinzukommen.

Zentrale `work/.gitconfig` als Verteiler

Die Datei C:/Arbeit/work/.gitconfig fungiert als Verteiler und entscheidet anhand des Pfads, welche kundenbezogene Konfiguration geladen wird:

[includeIf "gitdir/i:**/work/kunde-a/**"]
    path = C:/Arbeit/work/kunde-a/.gitconfig

[includeIf "gitdir/i:**/work/kunde-b/**"]
    path = C:/Arbeit/work/kunde-b/.gitconfig

alle Dateien heißen .gitconfig
Git unterscheidet ausschließlich anhand des Pfads, nicht anhand des Dateinamens
neue Kunden erfordern nur einen neuen Eintrag hier, nicht in der globalen Config

Kunden‑spezifische `.gitconfig`

Im jeweiligen Kundenordner liegt die eigentliche Identität:

[user]
    name = Kirsten Kluge
    email = kirsten@kunde-a.de
    useConfigOnly = true

Diese Konfiguration gilt automatisch für alle Repositories unterhalb dieses Kundenordners.

Technische Grenze von Git

Git kann keine .gitconfig automatisch aus dem Parent‑Ordner laden.
Alle Includes müssen explizit über einen festen Pfad erfolgen.

Das bedeutet:

ein vollständig dynamisches „nimm die `.gitconfig im aktuellen Kundenordner“ ist nicht möglich
ein zentraler Verteiler (work/.gitconfig) ist technisch unvermeidlich
der einheitliche Dateiname .gitconfig ist jedoch problemlos möglich

Hinweise & Best Practices

Für jede Identität empfiehlt sich ein eigener SSH‑Key
Optional: Commit‑Signing (GPG oder SSH) pro Identität
Die hier gezeigte Lösung ist robuster als git config --local, da sie automatisch greift

Quellen

Text und Inhalt entstanden mit freundlicher Unterstützung von
Compufreak345