If you code for your job during the day and work on personal projects at night, you’ve probably run into this problem: your machine only wants to remember one GitHub account at a time. You push a personal commit and it shows up under your work identity, or GitHub rejects the push because the wrong account doesn’t have access to that repo.

The fix isn’t complicated once you understand the two ways Git authenticates: SSH keys and HTTPS with Git Credential Manager (GCM). This guide covers both approaches, and works whether you’re on Windows, macOS, or Linux.

The Problem

By default, Git doesn’t know the difference between “work” and “personal” — it just uses whatever credentials or SSH key it finds first. If you’ve only ever set up one identity on your machine, every repo you clone tries to authenticate with that same account, regardless of which project it actually belongs to.

There are two solid ways to solve this:

1. SSH keys — separate key per account, routed automatically via host aliases
2. Git Credential Manager (GCM) — separate stored credentials per account, routed via per-folder config

Most developers pick one method and stick with it. SSH is generally preferred if your network allows it; GCM is the better option if your company blocks outbound SSH traffic (port 22), which is common on some corporate networks.

What Is Git Credential Manager?

Git Credential Manager (GCM) is a tool that securely stores your Git credentials — usernames, tokens, or OAuth sessions — so you’re not typing a password every time you push or pull over HTTPS. Instead of managing raw passwords, it talks to GitHub using secure tokens and stores them in your operating system’s native credential store:

• Windows → Windows Credential Manager
• macOS → Keychain
• Linux → a supported secret store (like libsecret, GNOME Keyring, or KWallet)

GCM comes bundled by default with Git for Windows, and can be installed separately on macOS and Linux. The main advantage for our use case is that it can store multiple credentials, keyed by URL — which means, with the right setup, it can hand out the correct GitHub token depending on which repo you’re working in, without you touching SSH at all.

You can check if you already have it installed by running:

git credential-manager --version

If that fails, we’ll cover installing it below.

Method 1: SSH Keys (Recommended if SSH isn’t blocked)

This method uses two separate SSH keys — one per GitHub account — and a config file that tells Git which key to use based on a host alias.

Step 1: Generate Two SSH Keys

The command is identical across Windows (Git Bash), macOS, and Linux terminals:

ssh-keygen -t ed25519 -C "you@personal-email.com" -f ~/.ssh/id_ed25519_personal
ssh-keygen -t ed25519 -C "you@work-email.com" -f ~/.ssh/id_ed25519_work

Press Enter to accept the file location shown. You can optionally set a passphrase for extra security — recommended, especially for your work key.

This creates four files in ~/.ssh/:

• id_ed25519_personal and id_ed25519_personal.pub
• id_ed25519_work and id_ed25519_work.pub

Windows note: ~/.ssh/ resolves to C:\Users\YourName\.ssh\. Git Bash handles the ~ shorthand automatically.

Step 2: Add Each Key to Its GitHub Account

Copy the public key contents for each:

cat ~/.ssh/id_ed25519_personal.pub
cat ~/.ssh/id_ed25519_work.pub

On macOS, you can pipe this straight to your clipboard:

pbcopy < ~/.ssh/id_ed25519_personal.pub

On Linux, use xclip (if installed):

xclip -sel clip < ~/.ssh/id_ed25519_personal.pub

On Windows (Git Bash):

clip < ~/.ssh/id_ed25519_personal.pub

Then on GitHub:

1. Log into the relevant account
2. Go to Settings → SSH and GPG keys → New SSH key
3. Paste the public key and save

Repeat for both accounts.

Step 3: Create an SSH Config File

Create or edit ~/.ssh/config (same path on all three platforms):

# Personal account
Host github.com-personal
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_personal
    IdentitiesOnly yes

# Work account
Host github.com-work
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_ed25519_work
    IdentitiesOnly yes

This creates two “virtual hosts” that both point to github.com, but each uses a different key.

Linux/macOS permissions: SSH is picky about file permissions. Run chmod 600 ~/.ssh/config and chmod 600 ~/.ssh/id_ed25519_* if you get permission warnings.

Step 4: Clone Using the Right Host Alias

# Personal project
git clone git@github.com-personal:yourusername/repo.git

# Work project
git clone git@github.com-work:yourorg/repo.git

For existing repos, update the remote instead of re-cloning:

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

Verify with:

git remote -v

Method 2: HTTPS with Git Credential Manager

This method skips SSH entirely and uses HTTPS URLs with GCM handling authentication. It’s the better choice if your work network blocks SSH.

Step 1: Install Git Credential Manager

Windows — GCM is included automatically with Git for Windows. Nothing extra to install.

macOS — install via Homebrew:

brew install --cask git-credential-manager

Linux — download the .deb (Debian/Ubuntu) or .tar.gz package from the GCM releases page and install:

# Debian/Ubuntu example
sudo dpkg -i gcm-linux_amd64.<version>.deb
git-credential-manager configure

Step 2: Generate a Personal Access Token for Each Account

GCM works best with fine-grained Personal Access Tokens (PATs) rather than passwords.

1. Log into each GitHub account
2. Go to Settings → Developer settings → Personal access tokens → Fine-grained tokens
3. Generate a token scoped to the relevant repos, with Contents: Read and write access
4. Save both tokens somewhere safe temporarily — you’ll enter them once during setup

Step 3: Use Separate Credentials Per Folder with includeIf

The trick to running two accounts through GCM is the same one used for Git identity: conditional includes, scoped by folder, that point to different credential storage namespaces.

In your global ~/.gitconfig:

[user]
    name = Your Personal Name
    email = you@personal-email.com

[credential]
    credentialStore = cache

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

Then create ~/.gitconfig-work:

[user]
    name = Your Work Name
    email = you@work-email.com

[credential "https://github.com"]
    useHttpPath = true

Setting useHttpPath = true tells GCM to store credentials per full URL path rather than just per host, which allows different tokens for different repo owners/orgs under github.com.

Step 4: Clone with HTTPS URLs

git clone https://github.com/yourusername/personal-repo.git ~/personal/personal-repo
git clone https://github.com/yourorg/work-repo.git ~/work/work-repo

The first time you push or pull each repo, GCM will prompt you to authenticate (browser-based OAuth login, or paste your PAT). It stores the credential against that repo’s path, so subsequent operations happen silently — and because the two repos live in different folders, they pick up different user.name/user.email values automatically via the includeIf block.

If you ever need to clear a stored credential and re-authenticate (e.g., you picked the wrong account by mistake):

git credential-manager erase

You’ll be prompted for the host, then it forgets that entry and asks again next time.

Recommended Folder Structure (Either Method)

Keep things predictable by separating projects into two top-level folders:

~/
├── work/
│   ├── project-a/
│   └── project-b/
└── personal/
    ├── side-project-1/
    └── side-project-2/

• Windows: C:\Users\YourName\work\ and C:\Users\YourName\personal\
• macOS/Linux: /Users/yourname/work/ and /Users/yourname/personal/ (or /home/yourname/...)

Anything cloned into work/ uses your work identity and credentials; anything in personal/ uses your personal ones — automatically, every time.

Quick Recap

Both methods achieve the same result: clone a repo once into the right folder, and every future push, pull, and commit uses the correct account automatically — no manual switching, no accidentally pushing personal code under your work identity, or vice versa.