Switching to a Company GitHub Account in VS Code

Fix commits still attributed to a personal account and unblock Vercel deployments after switching GitHub identities.

When you move from a personal GitHub account to a company one, signing out in VS Code is only half the job. Sign-out changes authentication (what credentials push your code) but leaves your commit identity (git config user.email) untouched. Vercel maps every commit's author email to a GitHub account, so if commits still carry your personal email — an account not authorized on the Vercel project — deployments get blocked even after you've "switched accounts."

This page covers switching both halves cleanly, plus the private-email push rejection (GH007) you'll likely hit on the way.

Why sign-out isn't enough

Two independent systems are in play:

Authentication — the credential (PAT / OAuth token) used to push. Controlled by VS Code's account sign-in and the OS credential store.
Commit identity — the user.name / user.email stamped into each commit. Controlled entirely by Git config, never by VS Code sign-out.

A blocked Vercel deploy after switching accounts is almost always the second one: commits are still authored with the personal email.

Fix the identity and auth

Check what's currently set

git config --global user.email
git config --global user.name
git config user.email   # run inside the repo — a repo-local value overrides global

You'll probably see the personal email come back.

Set the company identity

Use the company account's GitHub noreply address here rather than a real email — it avoids the push rejection covered below and never exposes a real address in history.

git config --global user.email "12345678+username@users.noreply.github.com"
git config --global user.name "Your Name"

Drop --global to set the identity per-repo instead. Useful if the same machine also pushes personal projects and you want to keep the two identities separate.

Clear the cached push credentials

VS Code's sign-out often leaves the old token in the OS credential store, so pushes still authenticate as the personal account. Remove it, then the next push prompts for fresh sign-in.

Open Credential Manager → Windows Credentials, find the git:https://github.com entry, and remove it.

Open Keychain Access, search for github.com, and delete the matching internet-password entry.

Re-author the queued commit

Any commit already made under the old identity keeps that author until rewritten. Fix the most recent one:

git commit --amend --reset-author --no-edit

--amend only rewrites the latest commit. Older commits in the branch keep their original author email. They won't re-trigger a push rejection (GitHub only blocks new pushes), but they also won't attribute to the company account. If that matters for the Vercel mapping, rewrite the branch history instead of a single commit.

Push

git push

Then confirm the author is correct:

git log -1 --format='%an <%ae>'

It should show the company name and the noreply address.

The `GH007` private-email rejection

If you set a real email (e.g. l.example@company.com) instead of the noreply address, the push is rejected with:

remote: error: GH007: Your push would publish a private email address.
! [remote rejected] main -> main (push declined due to email privacy restrictions)

This is unrelated to any "diverged branch / pull first" dialog — the push reached GitHub and was declined at the server. The company account has Keep my email address private enabled, with command-line pushes that expose the email blocked. Git wants to write your real address into public commit history; GitHub refuses.

Recommended fix — use the noreply address

Every account has a private relay in the form ID+username@users.noreply.github.com. Commits authored with it still attribute correctly, but the real email never appears anywhere.

Find it on the pushing account under Settings → Emails, shown beneath the "Keep my email address private" checkbox, then set it and re-author:

git config --global user.email "12345678+username@users.noreply.github.com"
git commit --amend --reset-author --no-edit
git push

Alternative — disable the protection

On GitHub: Settings → Emails → untick Block command line pushes that expose my email. The push then goes through with the real email embedded in every commit. Works, but the noreply route is the cleaner default, especially for public repos.

The noreply address must belong to the same account you're pushing as. Setting a noreply from a different account clears GH007 but attributes commits to the wrong identity — which puts you right back at the blocked Vercel deploy.

Check the repo namespace

Confirm whether the remote lives under a personal namespace or the company organization:

git remote -v

A remote like github.com/your-username/it-docs is a personal namespace. A company project should live under the organization (github.com/company-org/it-docs) — otherwise the repo is owned by a personal account, Vercel deploys from that personal repo, and you inherit ownership and access problems later. If it's personal, transfer it to the org before going further.

If Vercel still blocks the deploy

With correct authorship and a successful push, a lingering block usually means the Vercel project's Git integration is still linked to the personal account. Check the project's Settings → Git in Vercel and confirm the company account or org is the connected source.

Switching to a Company GitHub Account in VS Code

On this page