Living with Multiple Git-Personalities without Going Crazy

TL;DR

1. Change your git config based on the location where you clone your repository - jump there
2. Easily switch between different git accounts via SSH-key during clone - jump there

So... You know you have a problem.
You have known for quite some time.
Up until now you haven't been able to put your finger on it, but something was always bothering you. You have known there had to be others out there, facing the same issues. Although some of them must have come up with a solution by now, you didn't stumble across it yet.

But fear no more. Your search is over. You have finally come to the right place.

Forgive my exaggeration, but I hope you get my point. This is a feeling every one of us developers has once in a while. We continue to learn throughout our careers and often are fortunate enough to work together with other awesome developers from whose experiences we should always try to learn. This is why decided to start sharing those lessons and tricks as I come to learn them.

I dare say everybody of us found themselves banging their head against a wall in the past, struggling with some kind of issue or annoyance that turned out to be easily solvable - once you have the right trick up your sleeve.

One of those annoyances for me was handling git in different contexts. I use it for private projects as well as for work related projects. Additionally, since I work at a consulting company, I also work for varying clients.

Conditional Git Config

Although this is no must, I prefer slightly different appearances in all these contexts. I want my private projects to be associated with my private email address and work projects with my company address respectively. Some of the clients also provide their external developers with dedicated email addresses that I prefer to use in those cases.

Additionally, I find my name relatively long to type and just go with Alex. However, in a professional context I prefer to use my full name.

I know those settings can be adjusted for every repository I work on, but I prefer this to be automated. You might call it lazy, but I try to avoid it since I tend to forget doing it in time and get thrown out of my flow down the road.

This is where the .gitconfig comes into play. By default, git will store your global settings in this file within your home directory. My default private config looks like this:

# ~/.gitconfig
[user]
    name = Alex Kucksdorf
    email = <my_private_mail>

The real game changer there for me was learning about conditional includes. This enables me to do something like the following:

# ~/.gitconfig
[user]
    name = Alex Kucksdorf
    email = <my_private_mail>

[includeIf "gitdir:~/dev/work/"]
    path = .gitconfig-work
[includeIf "gitdir:~/dev/work/<client>/"]
    path = .gitconfig-<client>
...
# ~/.gitconfig-work
[user]
    name = Alexander Kucksdorf
    email = <my_work_mail>
...
# ~/.gitconfig-<client>
[user]
    name = Alexander Kucksdorf@it-economics
    email = <my_<client>_mail>

This way I only need to think about the folder where I clone the repository and my git config is automatically good to go.

Manage Accounts via SSH

Resulting from this, I have already been in the situation where I had multiple Github accounts because of client requests. Due to the requirement of using 2FA as well, I very much prefer to use SSH instead of username/password authentication. However, this means that I have to use different private keys, depending on which account I want the commit to be published with. An easy solution is to define a configuration at ~/.ssh/config like so:

# ~/.ssh/config
Host github.com-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_work

Host github.com-private
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa

After you have set up your SSH like this, all you need to is clone your repositories like this:

git clone [e-mail]-work:<organization>/<repo>.git

and it will automatically use the private key associated with your work account. The same can be achieved by changing your remote URLs on already cloned repositories respectively.