This article was originally published in our UncaughtException blog. Read this article in there by following this link.
Cover photo by Brina Blum on Unsplash.
I previously wrote about setting up multiple GitLab accounts, which works by relying mostly on SSH config files and using custom hosts as remotes for git repositories. You can read it by following this link: Setting up multiple GitLab accounts
The previous setup works, but I find it inconvenient having to use custom hosts when cloning repositories or for git remotes all the time, like:
$ git clone git@gitlab.com-work:work/repository.git
I recently (almost) had to deal with the same scenario, on GitHub this time (hence the title), so I decided to check if I can achieve a better setup. Turns out that there’s a better way to do it — one that does not rely on custom hosts or modifying any SSH config file.
In this article, we are going to assume that we have two GitHub accounts, personal@email.com
and work@email.com
. When working on work-related projects we want to commit and push our changes using our work account, while using our personal account for everything else.
We’re also going to assume that we’ve already defined global configs telling git to use our personal account. See this guide on how to do that.
Generate SSH keys for each user
GitHub does not allow us to use the same SSH key in multiple accounts, so we’ll have to create separate keys for each account. We can create SSH keys and add them to our SSH agent by following this guide from the GitHub Documentation.
Once we’re done, we will have two sets of SSH keys, e.g.:
-
~/.ssh/id_rsa
and~/.ssh/id_rsa.pub
(let’s use this for our personal account) -
~/.ssh/work_key
and~/.ssh/work_key.pub
Now add the SSH keys to their corresponding GitHub accounts. This guide shows us how to do that.
Committing as the correct user
We then modify our ~/.gitconfig
file to use our work account when we are inside a work-related repository. We are going to use “Conditional Includes” for that, which dynamically adds/removes configuration based on certain conditions. Let’s add the following snippet to our ~/.gitconfig
file:
[includeIf "gitdir:/path/to/work/repository/"]
[user]
email = "work@email.com"
This makes git override our global configs and use work@email.com
when committing changes inside the work repository. When in any other repository, our personal account will be used.
Do this for all work repositories
The way I personally structure my repositories on my file system is I place all work-related repositories inside the ~/work
directory. This makes it easier to enable the configs above for all work-related repositories by just using the work directory in the includeIf
directive:
[includeIf "gitdir:~/work/"]
Pushing as the correct user
When we push our commits now, they will be pushed to our personal GitHub account, even though we’ve already committed them using our work email. That’s because under the hood, git uses SSH, and SSH uses the id_rsa
key by default. So when GitHub receives the push, it will try to determine which user pushed the commits based on the SSH key used, which will turn out to be our personal account.
We can resolve this by using the work_key
SSH key when pushing to our work repositories. In SSH, this can be done through the -i
flag, like so:
$ ssh -i ~/.ssh/work_key ...
We can configure git to use a custom SSH command like above by setting core.sshCommand
. And since we only want to set it when we’re inside any work repository, we also conditionally include it inside the includeIf
directive:
[includeIf "gitdir:/path/to/work/repository/"]
[user]
email = "work@email.com"
[core]
sshCommand = "ssh -i ~/.ssh/work_key"
These configs now make git commit using our work email, as well as make GitHub associate commits with our work account when we push them 🎉.
Summary
We’ve managed to configure git to use different configs when committing and associating these commits to different GitHub accounts when pushing, based on what repository we are performing those changes — and we used conditional includes in git’s config file to achieve that.
I like this way better than the previous setup since it’s more convenient to use (no more custom hosts) and all the config changes only affect git (no more changing of SSH config files).
If you deal with these multiple GitHub accounts in a different way, please feel free to share with us how you do it as well!
Top comments (17)
Lot of steps to be be able to add a comment! Anyway, if you read this post and git is not using the correct information, maybe that's because you can't explicit set configurations after the
[includeIf]
. You must include a file instead.Only after reading the git-config documentation, and noticing that they talk a lot about a
path
property, I decided to move thesshCommand
to another file. And then it finally worked correctly. What I currently have:Arnelle, thanks for this post. It's way better then using custom hosts!
I don't know why but I can't get it done in my case. After using
ssh -i ~/.ssh/work_key
and thengit clone my_repo_url
, it still shows errors of no permission. I tried addcommand clause
as well but the result is still the same. Have no clues why it couldn't be done. Could you pls help?Hello! Hmm I can think of a few things you can check to troubleshoot this:
work_key
's public key to your GitHub account's SSH Keys?git@...
url (not sure if this makes a difference but worth trying hehe)Please let me know how it goes! :)
I had the same problem as you. I had to restart my Macbook in order for it to work.
This does not work for me and it took me half a day to debug to figure out why. Here's the thing:
Even though you have an
ssh -i
section in the git config, this does not work for pushing to remote repositories. This is because for some reason that git always prefers.ssh/config
and this defaults to my "user" key and not my "work" key. Therefore, pushing to a work-repository, even withssh -i
, it finds the personal user key first and I'll get a persmission denied for "user" error from github.Only setting up different hosts in
.ssh/config
fixed this for me. I know it was your entire point of this post to say, "the nicer way," but maybe you have just forgotten about this config?Or are you using the same SSH key for different accounts? I would not recommend doing that. Anyways, thank you for this article. :)
Hi Arnelle,
Thank's for this tip !
Is it possible to do something like this :
Thank's again !
From documentation I would say, no. ( git-scm.com/docs/git-config#Docume... ).
But I just checked it in WSL and it looks to work.
Correction. Iput:
[includeIf "gitdir:~/work/*/ome"]
[user]
email = "work@email.com"
And it matched
~/work/test
So it seems to match to much.or just ignores everything after a wildcard.
I would suggest using symlinks, but I see that you are using windows.
Thank's man !
@yafkari : it looks like it matches to much. Please read comment above.
Maybe if you are constrained to windows try using WSL and then symlinks there. (but works with Windows 10 only :( ).
I believe Afri is correct about pushing changes to a remote using the
~/.ssh/config
. I was able to workaround the issue by telling ssh to ignore the config files using the-F
option.Specifying the value
none
tells ssh to ignore all configuration files. (ssh doc)Thanks, this works really nicely on windows as of 09/2021. I only found your method because it turns out that my ISP's DNS servers block SSH connections to GitHub and I was trying every method. Yours is the best by the way.
This is exactly what I needed. Bless you.
I use
ssh-add
and it might cause some issues. Make sure the keys are added in the order ofcondition includes
thanks for sharing this with us 🎉
Thanks bai arnelle
You're welcome! 🎉
Some comments may only be visible to logged-in visitors. Sign in to view all comments.