Git Credentials, Personal Access Tokens & Git Credential Manager Explained

Over HTTPS, Git never knows your GitHub password — it hands GitHub a credential, which since 2021 is a personal access token (PAT) or an OAuth token, not your account password. On Windows, Git Credential Manager (GCM) is the middleman bundled with Git for Windows: it pops a browser sign-in, exchanges it for a token, and stores that token in Windows Credential Manager so future pushes are silent. Two accounts collide by default because GCM keys its storage per host (https://github.com) — one cached login wins everywhere. The escape hatch is useHttpPath, which keys storage per repository, or a multi-account client that manages the tokens for you.

Answer: For two accounts on HTTPS: turn on per-repository credentials (git config --global credential.https://github.com.useHttpPath true), sign in once per repository as its owner, and GCM remembers each login separately. Or use GITmaxed, which keeps one OAuth token per account and binds repositories to accounts natively.

The cast of characters

Term	What it is	Where it lives
Password	Your GitHub account password — no longer accepted for HTTPS Git operations (unless using a PAT as the password)	Your head / password manager
PAT (personal access token)	A string you mint in GitHub settings with scoped permissions; used as the password over HTTPS	Clipboard → credential store
OAuth token	What GCM obtains when you complete the browser sign-in; same role as a PAT, minted automatically	Credential store
Git Credential Manager (GCM)	The helper that runs the sign-in UI and persists tokens	Installed with Git for Windows; configured by credential.helper
Windows Credential Manager	The OS vault GCM writes into	Control Panel → Credential Manager; entries like git:https://github.com

What happens on your first HTTPS push

1. Git sees the remote is https://github.com/... and asks the credential helper for a login.
2. GCM finds none → opens a browser window → you approve the sign-in as (say) your personal account.
3. GCM receives an OAuth token, writes it to Windows Credential Manager under git:https://github.com.
4. Push proceeds; every later push replays the stored token silently.

Nothing is wrong yet — until the work repository, also https://github.com/..., reuses the same entry and pushes as your personal account.

The two-account fix: per-repository credentials

# key stored logins by full repository URL, not just the host
git config --global credential.https://github.com.useHttpPath true

cd ~/code/work-project
git push   # first push: sign in as WORK account — stored under this repo's path

cd ~/code/personal-project
git push   # first push: sign in as PERSONAL account — stored separately

With useHttpPath on, each repository gets its own credential entry, so the two sign-ins coexist. Existing wrong entries get replaced on the next sign-in prompt.

Minting a PAT manually (for tools without a browser flow)

1. As the target account: Settings → Developer settings → Personal access tokens.
2. Classic token: scope at least repo (add workflow if you push workflow files). Fine-grained token: select the specific repositories.
3. Copy the token once — GitHub won't show it again.
4. Use it as the password when a tool asks (or git remote set-url stays the same; the credential store supplies it).

Prefer GCM's browser flow when available — no token to copy, and expiry/revocation is centralized in GitHub settings.

Resetting and troubleshooting

Symptom	Fix
Pushes go to the wrong account	Enable useHttpPath, then run git credential reject for the repo, or delete the git:https://github.com entry in Credential Manager and sign in again as the right account
GCM never prompts; "Authentication failed"	A stale token is cached — git credential reject (input protocol=https, host=github.com, path=owner/repo + blank line) or erase the vault entry, then push
Token expired / revoked	Sign in again — GCM replaces the stored token on the next prompt
2FA account keeps failing	HTTPS needs a PAT or the GCM browser flow — account passwords are blocked with 2FA
Wrong account in VS Code / IDE	IDEs share GCM — fix the per-repo credential as above; the IDE inherits it

When to stop maintaining credentials yourself

Per-repository credentials work and are free — but you've just added global config, per-repo sign-ins, and a vault you must clean by hand. GITmaxed replaces the whole layer: each account is added once via browser OAuth, tokens are isolated per account, and each repository is bound to one account for every push and pull — no useHttpPath, no vault surgery, no PATs to rotate by hand. If you live in the terminal, keep GCM; if you work in a GUI day to day, the GUI should carry the credential layer.

Related questions answered (the same queries, one by one)

Why does Git ask for my password every time?

Nothing is being stored — GCM is missing or failing. Complete the browser sign-in once, or store a PAT, and the vault entry will persist.

Can I use my GitHub password for git push?

No — HTTPS Git requires a PAT or OAuth token since 2021; account passwords are rejected (and impossible with 2FA enabled).

How do I use two GitHub accounts over HTTPS?

Enable credential.https://github.com.useHttpPath, then sign in to each repository as its owning account on first push. GCM stores the logins separately per repository path.

Where are Git credentials stored on Windows?

In Windows Credential Manager as entries like git:https://github.com (or git:https://github.com/owner/repo with useHttpPath), written by Git Credential Manager.

How do I remove a stored Git credential?

Delete the git: entry in Control Panel → Credential Manager, or run git credential reject with the protocol/host/path.

Do I need a personal access token if I use Git Credential Manager?

Usually not — GCM's browser flow mints an OAuth token for you. A PAT is for tools without a browser prompt or for scripted access.

Does GITmaxed use Git Credential Manager?

No — it manages its own OAuth tokens, one per account, applied per repository binding. That's how it avoids credential collisions entirely.