Git Config ‘Switching’: Automatically Change Email and SSH Keys by Directory

The “Identity Crisis” Nightmare

Many of you have likely felt the embarrassment of accidentally using your personal email to commit code to a company project. The result? A completely unknown name appearing on the contribution board. When that happens, you have to laboriously git commit --amend dozens of commits, which is time-consuming and prone to merge conflicts.

This issue is very common when sharing a single computer for work, freelance projects, and Open Source contributions. Manually typing git config user.email for every newly cloned repo is tedious and easy to forget. One moment of carelessness, and your Git history becomes a messy blend of “work” and “personal.”

Instead of fixing mistakes, let Git automate your workflow using the includeIf feature. This is how I manage over 20 different projects without ever worrying about identity mix-ups.

5-Minute Automated Setup

Assume you organize your work with the following directory structure:

• ~/work/: Contains all company projects (SaaS, Outsourcing).
• ~/personal/: Where personal or learning projects are stored.

Step 1: Create Separate Config Files

First, separate the configuration for each environment. Create a .gitconfig-work file in your Home directory (~):

# ~/.gitconfig-work
[user]
    name = Nguyen Van A (Work)
    email = [email protected]

Similarly, create a .gitconfig-personal file for your private projects:

# ~/.gitconfig-personal
[user]
    name = DevCute9x
    email = [email protected]

Step 2: Activate includeIf in the Main Config

Open your main ~/.gitconfig file and add the following code at the end. This is where the magic happens:

# ~/.gitconfig
[user]
    name = Default Name
    email = [email protected]

# Automatically load config if inside the work directory
[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work

# Automatically load config if inside the personal directory
[includeIf "gitdir:~/personal/"]
    path = ~/.gitconfig-personal

Key point: You must include a trailing slash / at the end of the directory path. Without it, Git won’t recognize it as a root directory, and this feature won’t work.

How includeIf Works

Git operates on the principle of overriding. When you run a Git command, it first reads the global .gitconfig file. Then, it checks if the current directory matches any gitdir conditions. If there’s a match, Git loads additional settings from the path file to override previous values.

This approach requires you to organize your directories neatly. Simply cd into any repo within ~/work/, and Git will automatically recognize you as a company employee. Exit to ~/personal/, and you’re back to being yourself.

Advanced Tip: Automatically Switch SSH Keys

Changing your email only solves the visual part. Authentication is the real headache. If your company uses GitLab with a specific SSH Key, while you use GitHub with a different one, you usually have to configure a complex ~/.ssh/config file.

There’s a cleaner way: use core.sshCommand directly in the specific config file.

Update your ~/.gitconfig-work file:

[user]
    name = Nguyen Van A (Work)
    email = [email protected]
[core]
    sshCommand = "ssh -i ~/.ssh/id_rsa_work -o IdentitiesOnly=yes"

When you git push inside the work/ directory, Git will automatically use the correct work-related SSH Key. You no longer need to worry about ssh-add-ing the wrong key or being denied access due to incorrect credentials.

Real-World Tips from the Field

After years of use, I’ve gathered three important notes to avoid minor issues:

1. Verify with commands: Don’t guess. Type git config user.email as soon as you enter a new directory to see if Git has picked up the correct identity.
2. Usage on Windows: This OS is sometimes case-insensitive. You should use gitdir/i: instead of gitdir: to avoid path-related errors (e.g., [includeIf "gitdir/i:C:/Work/"]).
3. Priority Order: Files included later have the highest priority. Place general configurations in the base file and specific ones in the sub-files.

Separating your environments makes you look much more professional to your colleagues. Most importantly, it frees your brain from trivial tasks so you can focus on what matters most: Code.