Your Git username and email are the identity stamped onto every commit you make, and setting them correctly is the difference between a clean audit trail and a confusing, unattributable history. The two values live in Git's configuration, they are trivial to set, and yet a surprising number of security and compliance headaches trace back to them being wrong, missing, or misunderstood. This guide covers how to configure your Git username and email properly and why the details matter more than they first appear.
What these values actually do
When you run git commit, Git records who authored the commit using two fields: user.name and user.email. These are written into the commit object itself, so they travel with the history forever. On a platform like GitHub or GitLab, the email is what links a commit to a user account and populates the contribution graph, avatar, and attribution.
The important thing to understand up front is that these values are self-asserted. Git does not verify them. Nothing stops anyone from setting user.name and user.email to whatever they like. That is exactly why the security conversation around commit identity eventually leads to signing, which we will get to.
Setting your Git username and email
The most common setup is global configuration, which applies to every repository on your machine unless a repo overrides it:
git config --global user.name "Priya Mehta"
git config --global user.email "priya@example.com"
To confirm what is set:
git config --global --list
If you work across multiple identities, say a work email for company repositories and a personal one for open source, you set a per-repository value inside the specific repo:
cd ~/projects/work-repo
git config user.name "Priya Mehta"
git config user.email "priya@company.com"
Because there is no --global flag, this writes to the repository's local .git/config and takes precedence over the global setting for that repo only. Git resolves configuration in order of specificity: local overrides global, which overrides system.
Managing multiple identities cleanly
The per-repo approach works but relies on you remembering to set it in every clone, which is exactly the kind of manual step people forget. A cleaner pattern uses conditional includes in your global ~/.gitconfig:
[includeIf "gitdir:~/work/"]
path = ~/.gitconfig-work
[includeIf "gitdir:~/personal/"]
path = ~/.gitconfig-personal
Then ~/.gitconfig-work contains your work user.name and user.email, and the personal file contains the other set. Now any repo under ~/work/ automatically gets the work identity. This removes the "oops, I committed to the company repo with my personal email" mistake, which is both an attribution problem and, in some organizations, a policy violation.
Why the email matters for security and audit
Commit identity feeds directly into audit and accountability. In a SOC 2 or similar control environment, you want to demonstrate that changes to production code are attributable to specific, authorized people. If commits are landing with generic values like root@localhost or a stale email that no longer maps to anyone, your history is technically present but practically useless for investigation.
There is also a privacy angle. Committing with a personal email address to a public repository publishes that address permanently in the history, where scrapers will find it. GitHub offers a noreply address (username@users.noreply.github.com) precisely so you can keep contributions attributed without leaking a real inbox:
git config --global user.email "yourname@users.noreply.github.com"
The trust gap: why identity is not proof
Here is the part that trips people up. Because user.name and user.email are self-asserted and unverified, anyone can author a commit that appears to come from you. Set the email to a colleague's address, and their name and avatar show up on the commit. This is not a Git bug; it is how the format works. It means the identity on a commit is a claim, not evidence.
Closing that gap is what commit signing is for. When you sign commits with GPG, SSH, or S/MIME, you attach a cryptographic signature that a verifier can check against a key you control. Platforms then show a "Verified" badge, which tells reviewers the commit genuinely came from the holder of that key, not just from someone who typed the right email.
# Sign commits with your SSH key (Git 2.34+)
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
For teams that care about supply chain integrity, requiring signed commits on protected branches raises the bar meaningfully. It turns "this commit says it is from Priya" into "this commit is cryptographically tied to Priya's key." That distinction matters when you are reasoning about whether a change to your codebase is trustworthy, which is the same mindset behind broader DevSecOps practices.
Common mistakes and quick fixes
A few problems come up repeatedly. Committing with no identity set at all produces commits Git may attribute to a system default, which pollutes history. Fix it by setting the global values before your first commit on a new machine.
Realizing after the fact that a batch of commits used the wrong email is fixable, but rewriting history on a shared branch is disruptive. For unpushed local commits, git rebase with --amend on each, or the built-in tooling for bulk author rewrites, will correct them. For already-pushed public history, weigh the disruption of a force-push against simply setting the correct identity going forward.
Assuming the contribution graph updates instantly is another one. If your commits are not showing up under your account, the commit email almost certainly does not match a verified email on your platform account. Add the address to your account settings and the linkage catches up.
FAQ
What is the difference between global and local Git username and email?
Global values in ~/.gitconfig apply to every repository on your machine. Local values set inside a repo's .git/config apply only to that repo and override the global ones. Use local or conditional includes when you need different identities for work and personal projects.
Does my Git email have to be real?
It does not have to be a working inbox, but it should map to a verified email on your hosting platform if you want commits attributed to your account. Many people use a noreply address to keep attribution without exposing a real email in public history.
Can someone fake my Git username and email?
Yes. Both values are self-asserted and unverified by Git, so anyone can author a commit that appears to be from you. Commit signing with GPG or SSH closes this gap by cryptographically proving the commit came from your key.
How do I change the identity on commits I already made?
For local, unpushed commits you can amend or rebase to rewrite the author. For commits already pushed to a shared branch, rewriting history is disruptive, so usually the safer move is to correct your configuration and apply it going forward.