How to use multiple remote git Instances

Fri, 04 Feb 2022 22:00:00 +0100

Gits global config

When you create an empty git repository on one of the remote hosting platforms like GitLab, you usually get some setup commands displayed. Those are intended to help you set up your environment pretty quickly, but there are two commands which can screw things up for other remote hosts.

1
2


git config --global user.name "User"
git config --global user.email "user@mail-domain"

These commands should configure your username and email for the specific git account on the remote host to link the commits to your account. But using multiple remote Instances with different credentials leads to problems.
After running those two commands, you have globally set your credentials. For every git repository, those credentials will be used if they are not locally overwritten.

You could set those credentials as your global config if you want to use your university’s remote git Instance for multiple projects.

1
2


git config --global user.name "UniversityID"
git config --global user.email "UniversityID@uni-domain"

But these settings will immediately screw up your other Instance because those are set globally and will overwrite the previous one. The following commit you will make on the public server will be linked to your university account.

Solution: Use local config?

Just remove the --global option to fix this, right?

Not really, because now you must do this for every repository you are working on once. Git will display a message that you must set credentials if no global settings are configured.

If you use these Instances once, the solution is to set the credentials for the usual Instance globally and then set the others locally. So when you commit now, you will use your regular username and email because they are global. The local configs will be used when creating a commit in the repository for your ‘single-use’ Instance because they will temporarily overwrite the global settings.

But if you, like me, use multiple remote Instances regularly, always setting the local config can get tedious pretty fast.

Gitconfig

So let’s take a look at the gitconfig.

This config is usually located in your user directory under the name .gitconfig, whether you are on Windows or Linux. I can’t confirm this for Mac, but it might be similar.
If you used the first two commands to set your credentials globally, the gitconfig would contain an entry similar to this:

1
2
3


[user]
 name = User
 email = user@mail-domain

Those credentials will be used for every commit if they are not overwritten in the local config, which you can find under .git/config inside the repository. It will have the same user sections but with different usernames and emails.

So the next step is to change the config so that the correct username and email will be used for the chosen Instance.

Extending the config

My solution to this problem is to use the includeIf keyword inside the gitconfig. To make this work, I have a folder with all my repositories on my system. Inside this folder, I create subdirectories named after every remote host, so your directory structure may look something like this:

1
2
3
4


Git/
├─ github.com/
├─ gitlab.com/
├─ vousten.dev/

So, for one Instance, all the repositories are located in the folder named after this Instance.

Next, you create multiple separate gitconfigs for those Instances. I created a new folder inside the user directory called .gitconfigs. The dot will hide the folder by default and has a similar name to the original config. Inside this folder, I create new files named after those Instances, so it looks like this:

1
2
3
4


.gitconfigs/
├─ github.com
├─ gitlab.com
├─ vousten.dev

I add, or better yet, create, a user section inside those files, just like in the global config, and enter my credentials for the specific Instance. You could add other settings if you want them to be used only for the particular host.

To tell git that it should use these settings, add the following inside the global .gitconfig:

1
2
3
4
5
6


[includeIf "gitdir:Git/github.com/**"]
 path = ~/.gitconfigs/github.com
[includeIf "gitdir:Git/gitlab.com/**"]
 path = ~/.gitconfigs/gitlab.com
[includeIf "gitdir:Git/vousten.dev/**"]
 path = ~/.gitconfigs/vousten.dev

These config settings mean the specific Instance config will only be used if you use git in the host directory you created previously. So for every repository inside the Git/gitlab.com/ directory, the config .gitconfigs/gitlab.com is temporarily included in the global gitconfig.

Now you always have the proper credentials for every remote host unless you are working in the wrong directory, which may be the only downside of this solution. So you have to structure your repository thoughtfully to use this.

Multiple SSH Keys

This step is not needed to have the automatic credential system running, but I personally like it to have different SSH keys for different Instances. So howsoever you get your private key stolen, for one Instance, the other ones are still safe.

To do this, you must first create multiple SSH keys and store them inside .ssh\ located in the user directory. It is the same for Windows and Linux, like before. I created an extra directory for all my git keys inside this directory to have a bit of order in my file system.

The command to create an SSH key for one Instance could look something like this:

1

ssh-keygen -t ed25519 -f ~/.ssh/git/git.vousten.dev

You have to edit the config file to select which key should be used.

Assuming your file structure looks something like this:

1
2
3
4
5
6
7
8
9


.ssh/
├─ config
├─ git/
│ ├─ github.com
│ ├─ github.com.pub
│ ├─ gitlab.com
│ ├─ gitlab.com.pub
│ ├─ git.vousten.dev
│ ├─ git.vousten.dev.pub

You then have to add new hosts to the config file so that ssh knows what key it should use. The resulting config file for my case looks like this:

1
2
3
4
5
6


Host git.vousten.dev
 IdentityFile ~/.ssh/git/git.vousten.dev
Host github.com
 IdentityFile ~/.ssh/git/github.com
Host gitlab.com
 IdentityFile ~/.ssh/git/gitlab.com

If you connect now to a git host, the system will use the specified key, and thus you have a different key pair for every Instance.

Conclusion

The setup is straightforward and solves the problem of different credentials on different remote hosts. There may be even better solutions, but this is the one I like to use, and that works great for me. You may need to adapt it to your style or even search the internet, like me, if this will not work for your coding environment.
But I hope this gives you an idea for a custom solution, and as you see, this whole config is not complex, so that you can find an adaption to your system pretty quickly.