Managing Multiple Git Identities on One Machine

2026-02-05T00:00:00+00:00

TL;DR: Want separate Git emails per project? Just don’t use --global</code>.

The Problem: So I ran into this situation where I needed one project folder to use my university credentials while keeping my personal Gmail for literally everything else in VS Code. Classic identity crisis, but make it Git.

Honestly thought this would be a nightmare to set up, but Git actually makes it pretty straightforward once you know the trick.

Solution: Local vs Global Git Config</h3> Here is the thing I wish someone had told me earlier: stop using --global</code> for everything. I know it is tempting (one command and you are done!), but global configs apply to every single repository on your machine. Not ideal when you are trying to keep things separate. For personal identity (global): git config --global user.name "personal username" git config --global user.email "personal email"</code></pre> For uni project (local: run this inside that specific folder): git config user.name "uni username" git config user.email "uni email"</code></pre> See the difference? No --global</code> flag means the config only applies to that one repository. Problem solved. Paranoid and want to verify? I found this super helpful command to check which email was actually used for your last commit: git show -s --format='Author: %ae%nCommitter: %ce' HEAD</code></pre> This shows you both the author and committer email from your most recent commit. Saved me from some potential embarrassment when I wasn’t sure if I had configured things correctly! Bonus Learning: Git Reset Flags (Proceed with Caution)</h3> I also learned about git reset</code> and honestly it is Kind of terrifying. git reset --soft HEAD~1</code>: Removes your last commit but keeps all your changes staged. Perfect for those “oops, typo in the commit message” moments. Very forgiving, 10/10 would use again. </li> git reset --hard HEAD~1</code>: Deletes the last commit AND all your changes. Like completely GONE. Forever. No take-backs. (Yeah… never gonna try using --hard</code> unless I am absolutely certain and have sacrificed the appropriate offerings to the Git gods.) Small plot twist though: the commit isn’t truly gone, git reflog</code> can usually bring it back. Uncommitted changes are the part that’s really lost. </li> </ul> Real talk: Always double-check before using --hard</code>. Your past self worked hard on that code, and your future self will definitely not appreciate having to rewrite everything at midnight.

Tech Cafe - git

Git Archaeologist

Managing Multiple Git Identities on One Machine