3 Strategies for Seamlessly Managing Multiple Git Identities on One Machine

I spent twenty minutes rebase-shaming myself last week because I pushed a critical corporate feature under my old personal email address. It wasn’t a security breach, but seeing [email protected] in a professional audit log is the kind of minor humiliation that sticks with you.

If you use one laptop for both work and side projects, you’ve likely faced this. You want your work commits to use your corporate ID and your GitHub projects to use your personal one, and you want it to happen without you having to think about it.

Here are three ways to stop the identity leakage.

1. The "Conditional Include" (The Gold Standard)

Since Git 2.13, there has been a feature called includeIf. This is, quite frankly, the best way to handle multiple identities because it automates the switching based on where your code lives on your hard drive.

The logic is simple: if I'm working inside my ~/work/ folder, use my work config. Otherwise, use my global one.

First, create a separate config file for your work identity. I keep mine at ~/.gitconfig-work. Inside that file, just put the overrides:

# ~/.gitconfig-work
[user]
    name = Jane Doe
    email = [email protected]

Next, open your primary ~/.gitconfig and tell it to pull in those settings conditionally:

# ~/.gitconfig (Global)
[user]
    name = Jane Doe
    email = [email protected]

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

Why this works: Git checks the path of the repository you’re currently in. If it matches the gitdir pattern, it merges the settings from the specified path. It's set-and-forget. Just make sure your directory structure is organized.

2. The SSH Config Shuffle

Identity isn’t just about the email on the commit; it’s also about which SSH key you’re using to push. If you have a personal GitHub account and a work GitLab account (or a second GitHub account for work), your machine needs to know which key to hand over.

Most people try to manage this in Git, but it’s actually an SSH task. Edit your ~/.ssh/config file to create "host aliases."

# Personal GitHub
Host github.com
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_personal

# Work GitHub (using an alias)
Host github.com-work
  HostName github.com
  User git
  IdentityFile ~/.ssh/id_rsa_work

Now, here is the catch: when you clone a work repo, you have to slightly modify the URL. Instead of cloning [email protected]:org/repo.git, you’d run:

git clone [email protected]:org/repo.git

The github.com-work alias tells SSH to use the specific work key you defined. It feels a bit clunky at first, but it prevents that annoying "Permission denied (publickey)" error when you're trying to push to a private repo you definitely have access to.

3. The "Local-First" Nuclear Option

Sometimes you don't want a complex system. Maybe you’re working on a one-off project for a friend and don't want to move it into a specific folder. In these cases, you can set your configuration at the repository level.

Inside the repo, run:

git config --local user.email "[email protected]"

This creates a entry in .git/config inside that specific project. Local settings always trump global settings.

The Gotcha: You have to remember to do this *before* your first commit. If you've already committed, you’ll have to do a --amend --reset-author to fix the damage.

To help catch mistakes, you can set a "fake" global email that will obviously fail or look weird, forcing you to notice the mistake:

git config --global user.email "[email protected]"

Which one should you choose?

If you value your sanity, go with Strategy 1. Organize your files into ~/personal and ~/work and let includeIf do the heavy lifting. It removes the human element from the equation. Use Strategy 2 alongside it if you are juggling multiple sets of SSH keys.

The goal is to make your tools work for you, not the other way around. Stop editing your config files every time you switch tasks; you have more important things to build.