How To Use Different Git Configs

A lot of us are coding for an employer and privately or as a freelancer for multiple companies. You might want to associate commits for the different projects with a different user (e.g. email) or sign them differently (I think you should).

While you could configure Git per repository it becomes pretty cumbersome. Instead, configuring Git for a subset of all of your local repositories is much more handy. This is what I will be going to show you in this post.

Create Your Default, Global .gitconfig

First of all, we create our default, global .gitconfig by typing git config --global -e into your terminal. Let us keep this example simple and only config the name and email for our git user:

1
[user]
2
  name = Jannik Wempe
3
  email = jannik@wempe.dev

With that config, every one of your commits will be associated with the shown name and email – no matter where your repository is located on your machine.

Overriding Git Configuration For Some Repositories

In order to be able to override your Git configuration for multiple repositories at once we have to group them in a folder. I use a ~/code folder that looks like this:

1
.
2
├── work
3
└── private

I want to associate my commits in repositories that are located in ~/code/work with a different email address. Let us create a separate Git configuration for that: touch ~/.gitconfig-work. This is what that file looks like:

1
[user]
2
  email = jannik@other.com

We now have ~/.gitconfig and ~/.gitconfig-work in our home directory. But how to tell Git to use a different config for all repositories within ~/code/work?

By changing your ~/.gitconfig to this:

1
[user]
2
  name = Jannik Wempe
3
  email = jannik@wempe.dev
4

5
[includeIf "gitdir/i:~/code/work/"]
6
  path = ~/.gitconfig-work

gitdir/i is a condition telling Git to include the file at the given path if the Git repository is located in any sub-directory of ~/code/work/ (ending the path with / automatically adds /** and thus matching all sub-directories). The /i part configures the matching to be case-insensitive.

The include and includeIf sections allow you to include config directives from another source. These sections behave identically to each other with the exception that includeIf sections may be ignored if their condition does not evaluate to true; see “Conditional includes” below. — Git - git-config Documentation

The content of ~/.gitconfig-work will be inserted at the exact position where it is mentioned. That is why it will override previous configurations with the same (and why the includes should be at the end of the file). This way you could effectively append any configuration to your default .gitconfig – not just the user property.

With this config, any new commit in any repository located within ~/code/work will be associated with the email configured in .gitconfig-work. Et voilá, we have overridden the Git configuration for multiple Git repositories at once.

Check Which Config Is Active

gitdir only matches inside a Git repository, so run this from within a repository in ~/code/work:

1
git config --show-origin user.email
2
# file:/Users/jannik/.gitconfig-work  jannik@other.com

--show-origin prints the file a value comes from. If you still see ~/.gitconfig, check the path in your includeIf (including the trailing /).

Multiple GitHub Accounts With Different SSH Keys

A different email is often not enough: if you have a separate GitHub account for work, you need a separate SSH key, too. includeIf can handle that as well, because core.sshCommand is just another config value. Add it to ~/.gitconfig-work:

1
[user]
2
  email = jannik@other.com
3
[core]
4
  sshCommand = ssh -i ~/.ssh/id_ed25519_work -o IdentitiesOnly=yes

Every git fetch and git push in a repository within ~/code/work now authenticates with the work key. IdentitiesOnly=yes stops SSH from offering the keys loaded in your ssh-agent, e.g. your personal key, which GitHub would accept and map to the wrong account. It doesn’t ignore keys configured via IdentityFile in ~/.ssh/config, though: if you set one for Host github.com or Host *, SSH can still offer it, so remove it there.

The same goes for commit signing. If you sign with SSH keys, set a different user.signingKey in the included file:

1
[user]
2
  email = jannik@other.com
3
  signingKey = ~/.ssh/id_ed25519_work.pub

Match by Remote URL Instead of Folder

If you don’t want to sort repositories into folders, Git 2.36+ can match on the remote URL with hasconfig:remote.*.url::

1
[includeIf "hasconfig:remote.*.url:git@github.com:company/**"]
2
  path = ~/.gitconfig-work

Any repository with a remote pointing to the company organization now uses the work config, no matter where it lives on disk. One restriction: files included this way must not define remote URLs themselves.

Conclusion

You can stitch together Git configuration files by leveraging include and includeIf. The conditional includeIf allows us to conditionally overwrite certain configurations: your email, your signing key, or the SSH key to use for a separate GitHub account. Match by directory with gitdir or by remote with hasconfig:remote.*.url.