DEV Community

Sandeep Bansod
Sandeep Bansod

Posted on

I Used the Wrong Git Email for 2 Weeks — And No One Noticed

#git #devtool #ssh #productivity

I accidentally committed 2 weeks of client work using my personal email.

No warnings.
No errors.
No clue it was happening.

I only noticed after pushing everything to GitHub.

Here's the thing nobody tells you when you start freelancing alongside a full-time job: Git has no idea you're two different people depending on which folder you're in.

I found this out the hard way.

I'd been heads-down on a client dashboard project — late nights, quick commits, shipping fast. Then one morning I opened GitHub to review a PR and noticed something. Every single commit. Every one. Author: sandeep@personal.com.

Not sandeep@work.com. Not the email the client hired. My personal one.

I had three client projects on that machine. Same story across all of them. Two weeks of commits. All from the wrong person, technically.

I didn't tell the client. I just fixed it and moved on. But it bothered me for days — not the mistake, the fact that I had no idea it was happening.

Why It Happens (and Why It's Not Obvious)

Git stores your identity in a config file at ~/.gitconfig. That's your global config. It applies everywhere on your machine unless something overrides it.

# this is probably set to whatever you used when you first installed Git
git config --global user.email
# → sandeep@personal.com
Enter fullscreen mode Exit fullscreen mode

When you create or clone a repo, that global config is what Git uses — silently, automatically, every commit — until you tell it otherwise for that specific repo.

Most developers never do. Why would you? You set it up once years ago and forgot about it.

The problem only surfaces when you're juggling multiple contexts on one machine. Personal projects. Client work. A side job. A company laptop you also use for open source. Suddenly one identity doesn't cover it anymore.

The First Thing I Tried (Which Doesn't Really Solve It) 

cd ~/clients/acme-dashboard
git config --local user.email "sandeep@work.com"
Enter fullscreen mode Exit fullscreen mode

This works. It sets the email just for that repo by writing to .git/config inside it. Problem solved for this repo.

But I had eleven client repos. I went through all of them. Felt productive. Two days later I cloned a new one, started committing immediately, and forgot to run the command. Three commits in before I caught it.

--local is a fix for the symptom, not the cause. The cause is that you have to remember — and you won't, every time.

The Fix I Actually Use Now

Git has something called includeIf. It lets you load a different config file depending on which directory you're working in.

You set it up once. Then it just runs — automatically, in the background, every time you open a terminal in that folder. You never think about it again.

Here's how I set it up:

First, I organised my projects into folders by who I am when I work on them:

~/
├── clients/     ← freelance work
├── work/        ← day job
└── personal/    ← my own stuff
Enter fullscreen mode Exit fullscreen mode

That folder structure is the trigger. Everything under ~/clients/ gets one identity. Everything under ~/personal/ gets another.

Then I created a config file for each identity:

# ~/.gitconfig-clients
[user]
    name  = Sandeep
    email = sandeep@work.com
Enter fullscreen mode Exit fullscreen mode 
# ~/.gitconfig-personal
[user]
    name  = Sandeep
    email = sandeep@personal.com
Enter fullscreen mode Exit fullscreen mode

Then I added three lines to my global ~/.gitconfig:

[user]
    name  = Sandeep
    email = sandeep@personal.com   # the default fallback

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

[includeIf "gitdir:~/work/"]
    path = ~/.gitconfig-work
Enter fullscreen mode Exit fullscreen mode

That's the whole thing. When Git runs inside any repo under ~/clients/, it loads ~/.gitconfig-clients. The work email overrides the global personal one. When you're in ~/personal/, the global applies. Everything else gets the fallback.

Verify it:

cd ~/clients/acme-dashboard
git config user.email
# sandeep@work.com ✓

cd ~/personal/my-blog
git config user.email
# sandeep@personal.com ✓
Enter fullscreen mode Exit fullscreen mode

No command after cloning. No checklist. No forgetting.

And when something looks wrong, this tells you exactly which file is responsible:

git config --show-origin user.email
# file:/Users/sandeep/.gitconfig-clients    sandeep@work.com
Enter fullscreen mode Exit fullscreen mode

What About Two Different GitHub Accounts?

This is a separate problem that looks similar but isn't.

user.email controls what shows up in the commit author line. That's metadata. It has nothing to do with which GitHub account you're authenticated as when you push.

If you have a work GitHub account and a personal GitHub account, you need separate SSH keys. Otherwise you'll be authenticated as the same account no matter what email the commit shows.

# one key for each account
ssh-keygen -t ed25519 -f ~/.ssh/id_work     -C "work"
ssh-keygen -t ed25519 -f ~/.ssh/id_personal -C "personal"
Enter fullscreen mode Exit fullscreen mode

Add each public key to the matching GitHub account. Then set up ~/.ssh/config so Git knows which key to use for which host:

Host github-work
    HostName     github.com
    User         git
    IdentityFile ~/.ssh/id_work

Host github-personal
    HostName     github.com
    User         git
    IdentityFile ~/.ssh/id_personal
Enter fullscreen mode Exit fullscreen mode

Now clone using the alias instead of github.com:

git clone git@github-work:client-org/project.git
git clone git@github-personal:sandeep007/blog.git
Enter fullscreen mode Exit fullscreen mode

Test that each one works:

ssh -T git@github-work
# Hi work-sandeep! You've successfully authenticated.

ssh -T git@github-personal
# Hi sandeep! You've successfully authenticated.
Enter fullscreen mode Exit fullscreen mode

The Things That Will Trip You Up

The trailing slash matters. gitdir:~/clients and gitdir:~/clients/ are different. The version without the slash may not match subdirectories reliably. Always include it.

Check config from inside the repo. Running git config user.email outside a Git repo always returns the global value. If you're trying to verify it's working, cd into the actual project first.

The folder is the contract. Clone a client project into ~/personal/ by accident and it gets the personal identity. includeIf doesn't know what the project is — it only knows where .git lives. Respect the folder structure.

Windows needs full paths. The ~/ shorthand doesn't work reliably in gitdir: conditions on Windows. Use the full path instead: gitdir:C:/Users/Sandeep/clients/.

Honest Takeaway

I wasted two weeks of commit history and some amount of professional credibility because I didn't know this existed. The fix took me about ten minutes to set up once I found it.

includeIf is one of those Git features that feels almost too simple — you put it in one file and then you just never have to think about it again. The folder structure becomes the rule. Git enforces it silently.

If you work on more than one type of project on the same machine, set this up today. It costs you nothing and saves you from the specific embarrassment of a client asking who is writing all their code.

It takes 10 minutes — and can save your professional reputation.

If you found this useful, I write about TypeScript, Node.js, Security and DevOps
Follow Stack Dev Life for more real-world dev mistakes & fixes.
*Originally published at [stackdevlife.com]

Top comments (0)