Als Freiberufler bin ich regelmäßig bei verschiedenen Kunden im Einsatz. Teilweise auch parallel. Viele nutzen davon auch Git zur Versionskontrolle. Dies ist generell ein gute Entwicklung die ich beobachte.
Globale E-Mail Konfiguration
Jedoch habe ich lange Zeit in der global git config immer meine E-Mail Adresse eingetragen, ist ja so einfach.
git config --global user.email me@privatemail.com
Was mich dabei schon lange ein wenig stört ist dass dies halt dann bei jedem Commit mit eingetragen wird. In welchem Repository auch immer ich Commits mache. Auch in Repositories die ich vielleicht mit einer anderen E-Mail Adresse committen muss. Eine die zum Kunden passt.
Dafür kann man nun für das spezielle Repository eine eigenen E-Mail hinterlagen.
git config --local user.email me@clienmailt.com
Keine Globale E-Mail Konfiguration
Soweit so gut, jedoch bin ich nur ein Mensch und dieser vergisst das schonmal. Und schon committe ich aus versehen mit der globalen E-Mail Adresse. Gerade wenn man mit mehreren Repositories jongliert, sich ein frisches klont weil man etwas nachschauen und fixen will. Der Alltag halt.
Damit dies ausversehen nicht mehr passiert habe ich mich dazu entschlossen keine globale E-Mail Adresse mehr zu hinterlegen.
git config --global --unset user.email
Dann bekommt an bei einem Commit eine fehlermeldung um die Ohren gehauen, dass man doch bitte seine Default Identity setzen soll. Dies kann man dann ignorieren und für das lokale repository die E-Mail Adresse eintragen. Dies muss man dann immer zum ersten Commit in das Repository machen und das wärs dann. Korrekte E-Mail zum Repository.
Wünsche
Gewünscht hätte ich mir jedoch eine art root .gitconfig die ich einen Ordner legen kann und dann werden in allen untergeordneten die Einstellungen übernommen. In einer Hierarchie wie bei etlichen andren Tools (e.g. Nuget, Internet Information Service usw.). Dies gibt leider so nicht.
Doch dann der Tweet https://twitter.com/Philco78/status/877840330296442882 von Phil Scott.
Also check out git conditional includes. Let's you have a folder for each company and a config based on the path https://git-scm.com/docs/git-config#_includes
Update 1: Dazu ist Git erst ab Version 2.13 in der Lage
Git Konfiguration je Ordner
Das habe ich gemacht, [includeif] war fast genau dass was ich gesucht habe. Mit [includeif] kann ich einen Pfad angeben für den Git dann eine zusätzlich angegebene .gitconfig verwendet.
Dieser Pfad kann ein globbing Pattern sein, und wenn man nun alle Repositories für einen bestimmten Kunden in einem Ordner hat man eine spezifische Konfiguration für einen Ordner.
In meinem konkreten Fall bedeutet dies dass ich damit nicht mehr für jedes Repository einzeln die E-Mail Adresse eintragen muss. Sondern dies implizit über den Pfad stattfindet in dem sich das Repository befindet.
Das Beispiel
globale .gitconfig
[user]
name = Albert Weinert
useconfigonly = true
[includeif "gitdir:**/Client1/**/.git"]
path = .gitconfig.client1
[includeif "gitdir:**/Client2/**/.git"]
path = .gitconfig.client
[includeif "gitdir:**/Private/**/.git"]
path = .gitconfig.private
Update 2: Git versucht sich in Domain Konfigurationen eine E-Mail Adresse abzuleiten.Mit useconfigonly kann man dies verhindern.
Für die Bedeutung von gitdir: und andere feinheiten schaue bitte in die Git Documentation dazu.
Hier nun die passenden spezifischen Git Konfigurationen
.gitconfig.client1
[user]
email = a.weinert@client1.mail
.gitconfig.client2
[user]
email = a.weinert@client2.com
.gitconfig.private
[user]
email = info@der-albert.com
Woher kommt nun was?
Ich habe weiterhin keine globale E-Mail Adresse hinterlegt. Somit werde ich bei neuen Kunden daran erinnert eine spezifische Konfiguration anzulegen.
Die E-Mail Adresse ist natürlich nur eine Möglichkeit, man kann natürlich jegliche Git-Konfiguration darüber steuern.
Um Konfigurationsüberladungen die man sich damit einfängt zu diagnostizieren kann man
git config --global --list --includes
verwenden. Damit sieht man, passend zu aktuellen Repository, welcher Wert aus welcher Datei stammt.
Update 3: Leider kann Visual Studio zum heutigen Stand noch nicht damit umgehen. Da es unter anderem auf libgit2 setzt und nicht überall Git selbst verwendet. Aber dafür ist ein PR für libgit2 anhängig, keine Ahnung wann diese Version dann in Visual Studio einfließt. Es schadet sicher nicht für diesen UserVoice Vorschlag für Visual Studio abzustimmen.
Update 4: Die aktuelle Version von Visual Studio 2017 (jetzt 15.5) hat damit keine Probleme mehr.