If you’re anything like me, you probably like to keep work tidy and home projects even tidier. And then one day you realise you’ve ended up with two GitHub accounts on the same Mac. It all seems fine until you accidentally commit a personal configuration file into a work repo or Git politely tells you you don’t have permission to push… because you’re logged in as the wrong person.

This guide walks through a clean, mistake-proof way to run two GitHub accounts on one Mac using SSH keys and a simple directory layout. It includes the exact setup, plus the troubleshooting steps you’ll want when things don’t behave the way they should.

Here’s the thing: once you set it up properly, switching between two accounts becomes something you never think about again.

Why SSH is the safest way to run two accounts

SSH lets you tell your Mac exactly which key belongs to which GitHub account. Since keys are attached to accounts on GitHub itself, you can’t accidentally use the wrong one. Your machine will either authenticate cleanly or politely refuse you.

Instead of trying to make GitHub guess which account you meant to use, you tell it outright by using two host names:

• github.com for personal

• github-work (or any name you choose) for work

Each hostname maps to a different SSH key.

Step 1: Generate clear, separate SSH keys

Run these in your Terminal:

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_personal

ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_work

This gives you two distinct keys, each with its own comment so you know exactly who they belong to.

Then load them into the agent:

eval "$(ssh-agent -s)"

ssh-add -K ~/.ssh/id_ed25519_personal

ssh-add -K ~/.ssh/id_ed25519_work

Step 2: Add each public key to the correct GitHub account

Grab each .pub file:

cat ~/.ssh/id_ed25519_personal.pub

cat ~/.ssh/id_ed25519_work.pub

Add each one to the matching profile under GitHub → Settings → SSH Keys.

This is what locks the keys to their rightful accounts.

Step 3: Create a simple SSH config that knows which key is for what

Your ~/.ssh/config should look like this:

Host *

AddKeysToAgent yes

UseKeychain yes Host github.com

HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_personal

IdentitiesOnly yes Host github-work HostName github.com

User git

IdentityFile ~/.ssh/id_ed25519_work

IdentitiesOnly yes

This is the heart of the whole setup. When your repo uses the hostname github-work, the SSH client uses the work key. When it sees github.com, it sticks to your personal one.

Step 4: Use separate folders to keep your identities clean

A dead-simple directory layout keeps your brain and Git’s configuration in sync.

For example:

~/Projects/personal/

~/Projects/work/

You don’t have to use this exact layout, but having two base folders makes troubleshooting far easier.

Step 5: Let Git automatically apply different identities

You can tell Git to automatically switch names and emails based on the folder you’re in.

Create two identity files:

~/.gitconfig-personal:

[user]

name = Your Name

email = [email protected]

~/.gitconfig-work:

[user]

name = Your Work Name

email = [email protected]

Then update your main ~/.gitconfig:

[user] name = Default Name

email = [email protected]

[includeIf "gitdir:/Users/yourname/Projects/personal/"]

path = /Users/yourname/.gitconfig-personal

[includeIf "gitdir:/Users/yourname/Projects/work/"]

path = /Users/yourname/.gitconfig-work

Use absolute paths for reliability.

Now, whenever you’re in a repo under personal/, Git will automatically use your personal name and email. Same thing for work.

Step 6: Clone using the right host

This is where you actually choose the identity.

Personal repo:

git clone [email protected]:yourusername/some-repo.git

Work repo:

git clone git@github-work:workusername/work-repo.git

That one small change in the hostname keeps the whole world tidy.

Step 7: How VS Code and GitHub Desktop behave

VS Code

VS Code simply follows whatever Git and SSH do. If you open a repo from the personal folder, it uses your personal identity. If you open a work repo, it uses the work one. Nothing special to configure.

GitHub Desktop

This one is a little different. GitHub Desktop only signs into one GitHub account at a time. But it still honours repo-level SSH configuration, so you can safely:

1. Clone using the Terminal

2. Add the repo to GitHub Desktop

3. Commit and push normally

It will use the right SSH key automatically because Git handles the authentication, not the Desktop app.

Troubleshooting when Git doesn’t switch identities

This is the bit most people end up needing at least once.

Work through these steps in order.

1. Make sure you’re actually inside a Git repo

Run:

git rev-parse --show-toplevel

If that errors, Git can’t load any identity rules.

2. Check whether Git is loading your identity files

Run:

git config --list --show-origin | grep -i user

This tells you:

• Which files are loaded

• Which file provided the active email

• Whether the include files were seen at all

If you don’t see .gitconfig-personal or .gitconfig-work, the path doesn’t match.

3. Use absolute paths in your include rules

Git sometimes struggles with ~.

Change:

gitdir:~/Projects/personal/

to:

gitdir:/Users/yourname/Projects/personal/

Then test again.

4. Confirm that the key files exist

Check:

cat ~/.gitconfig-personal cat ~/.gitconfig-work

If either file is empty or missing a [user] block, Git won’t override anything.

5. Check for a local override inside

.git/config

Inside the repo:

cat .git/config | grep -A2 "\[user\]"

If that repo has its own user.email, Git will ignore your include rules.

Remove overrides with:

git config --unset user.email git config --unset user.name

6. Try matching a specific repo path to confirm the pattern

If your pattern still doesn’t fire, temporarily set something like:

[includeIf "gitdir:/Users/yourname/Projects/personal/example-repo/"]

path = /Users/yourname/.gitconfig-personal

Then run:

git config user.email

If that works, it means your broader path pattern needs adjusting. Oh, didn't I forget to mention the repo path is case sensitive? /Users/yourname/Projects/personal/example-repo/ is not the same as /Users/yourname/Projects/Personal/Example-repo/

7. Make sure your Git version supports includeIf

Run:

git --version

You’ll want 2.13 or newer.

8. Check SSH host names match your remotes

Run:

git remote -v

If a work repo shows:

[email protected]:workuser/work-repo.git

then Git is trying to use your personal key.

Fix it with:

git remote set-url origin git@github-work:workuser/work-repo.git

Wrap-up

There’s something satisfying about having a Mac that quietly knows which GitHub identity to use without second-guessing anything. The whole setup comes down to:

• two SSH keys

• two host names

• a directory structure

• a couple of small Git include files

Once you’ve got that sorted, it’s smooth sailing. And if something ever acts strangely, the troubleshooting steps will get you out of trouble pretty quickly.