Setup Git for work & personal GitHub accounts
So you joined a new company and made a dedicated GitHub account for work. Maybe you thought it would be more secure, maybe you were feeling adventurous or maybe you thought that's what hardcore engineers do.
5 days later you're pulling your hair trying to make Git play nice with multiple GitHub accounts. You find articles that assume a lot and still the end result is painful to use. You're already regretting it but time travel doesn't exist yet so you're stuck with your poor life choices. Fret not! I have suffered the pain and wrote this article to make it smooth sailing for you.
Link to this headingQuick summary of what I'll cover
- How to organize your Work repos locally.
- Make git commit auto-select Work or Personal E-mail.
- Set up remote urls for Work repos differently.
- Link your GitHub accounts with dedicated SSH keys.
- Customize your VS Code extensions for Work repos.
Link to this headingHow to organize your Work repos locally
First, we'll need to keep all our Work repos in a common directory so it's easy for Git to differentiate Work repos from Personal repos. Here's how I like to keep it.
/Users/aditya (home directory)├── Coding├── work│ ├── secret-work-repo│ ├── billion-dollar-mvp│ ├── legacy_monolith│ └── one_person_microservice│└── personal├── website├── vite-react-ssr├── failed_indie_product└── msw-storybook-addon
Now all Work repos are inside ~/Coding/work
and all personal repos are inside ~/Coding/personal
. If you use different directory names, make sure to modify what you copy from this article accordingly.
Link to this headingMake git commit auto-select Work or Personal E-mail
While setting up Git on a new system, we usually add a global name
and email
. On making commits, Git uses this info to attach author details. That's how we can later identify who made the commit in git log
. But this config is global, which means all repos would use the same details.
However, we want that our commits inside Work repos should use the E-mail of our Work GitHub account. Whereas for the commits we make inside Personal repos, the E-mail should be of our Personal GitHub account.
One option is to not set these details globally. Instead in each repo set the details locally. But that's so tedious. Here's a much better way.
Open the global git config file located at ~/.gitconfig
. It would look like this.
# This is Git's per-user configuration file.[user]name = Your Nameemail = email_personal@gmail.com
Modify the .gitconfig
file to look like the code shown below. We're telling Git to use a separate config file based on which repo it is running in.
# This is Git's per-user configuration file.[include]path = ~/git-personal.conf[includeIf "gitdir:~/Coding/work/"]path = ~/git-work.conf
By having all our Work repos inside one directory it becomes easy to choose a work-specific git config file conditionally. The config which is common in both can stay inside .gitconfig
.
Now, let's create these two config files in the home directory. Change the E-mail values in both files with your respective ones.
# Personal git config[user]name = Your Nameemail = email_personal@gmail.com
# Work git config[user]name = Your Nameemail = email_work@org_domain.com
You can check if the right E-mail is coming by running git config user.email
in the respective repo.
Link to this headingSet up remote urls for Work repos differently.
When Work repos sync with GitHub, they should use the credentials of our Work account instead of Personal account. For that you'll need to edit the remote urls of Work repos. No change is required in Personal repos.
You have a Work repo at github.com/org_name/repo_name and you've cloned it using the SSH option. Then on your local repo, the origin remote would point to git@github.com:org_name/repo_name.git
.
We'll copy that url into an original
remote and set a slightly different url as origin
remote by running these commands.
git remote add original git@github.com:org_name/repo_name.gitgit remote set-url origin git@github-work:org_name/repo_name.git
To verify if you've done this correctly, run git remote -v
. The result should be similar to the snippet below. Repeat the remote url change in the remaining Work repos.
origin git@github-work:org_name/repo_name.git (fetch)origin git@github-work:org_name/repo_name.git (push)original git@github.com:org_name/repo_name.git (fetch)original git@github.com:org_name/repo_name.git (push)
Link to this headingLink your GitHub accounts with dedicated SSH keys.
Now that the remote urls of Work repos are different, we can use that to pick the right SSH key when we sync to GitHub. But you may not multiple SSH keys setup, so I'll cover that first.
Link to this headingGenerate an SSH key pair for both Work & Personal Accounts
Run the following code to generate two sets of SSH keys. Replace the E-mail values with your GitHub ones. You can change the passphrase to what you like or remove that flag. For me, having two different passphrases acts like an extra reminder of which GitHub account I'm using on code push.
# Enter .ssh directorycd ~/.ssh# Generate SSH key for Personal accountssh-keygen -t rsa -f "id_rsa_personal" -C "email_personal@gmail.com" -P "pass_personal"# Generate SSH key for Work accountssh-keygen -t rsa -f "id_rsa_work" -C "email_work@org_domain.com" -P "pass_work"
If the above commands ran correctly you should see the four files in .ssh
directory.
~/.ssh├── id_rsa_personal (private key for Personal account)├── id_rsa_personal.pub (public key for Personal account)├── id_rsa_work (private key for Work account)├── id_rsa_work.pub (public key for Work account)├── config└── known_hosts
Link to this headingAdd respective SSH public key in your GitHub accounts.
Next, we need to add each public key to its respective GitHub account. For the Work account, here are the steps.
- Copy the contents of
id_rsa_work.pub
. - Login to your GitHub Work account.
- Go to the Add SSH Key page.
- Provide a title like "Macbook Pro".
- Paste the contents of public key into the "Key" field.
- Click the Add SSH Key button and complete the password confirmation.
You need to do the same for your Personal account. There you'll paste the content of id_rsa_personal.pub
after logging into your Personal GitHub account. If you need a detailed walkthrough with pictures, check the official GitHub Docs.
Link to this headingAdd configuration to choose SSH key based on remote origin path
As far as GitHub is concerned, only one small step is remaining. We need to tell SSH to pick the right key depending on which repo we're pushing from.
Create a file called config
inside .ssh
folder if one doesn't exist already. Then paste this snippet.
# Personal AccountHost github.comHostName github.comUser gitIdentityFile ~/.ssh/id_rsa_personal# Work AccountHost github-workHostName github.comUser gitIdentityFile ~/.ssh/id_rsa_work
Since we modified the origin
remote urls of Work repos, we can now use that to pick the id_rsa_work
key. If in a Work repo you forgot to change the remote url then it will try to use your Personal key which wouldn't have access. If that happens, now you know what to do.
Link to this headingCustomize your VS Code extensions for Work repos.
Since we changed the origin remote url for Work repos, some VS Code extensions might not behave properly. I faced problems using Git Blame and Git Link. If you use extensions like these, here's a bonus tip on how to fix them.
First, make a dedicated VS Code workspace for your Work repos. It's a great way to keep your VS Code settings scoped to projects. Then using Command Palette open the Workspace Settings (JSON)
. Copy the highlighted lines from below and paste them inside the settings
key.
{"folders": [...],"settings": {"gitblame.remoteName": "original","gitlink.defaultRemote": "original"}}
Do you remember we added a dedicated git remote called original
to store the actual url of the Work repo? Here we're telling the extensions to use that remote when interacting with GitHub.
Link to this headingConclusion
I know it's a chore going through all these steps, but at least now you have one place for future reference. Share it with new joiners in your team who are also considering multiple account setup. It might save them some hours and a couple of hair strands.