`git remote -v` Is the First Command You Should Run When Push, Pull, or Clone Behavior Stops Matching the Repo You Thought You Had
A practical guide to `git remote -v` for checking where a repository actually fetches from and pushes to before you debug the wrong GitHub repo, branch, or credential setup.
Why this command matters: a surprising amount of Git confusion is not about commits. It is about talking to the wrong remote and not realizing it until too late.
If git push fails unexpectedly, a pull request looks like it came from the wrong fork, or git pull brings in changes you did not expect, the fastest first check is often not another push attempt. It is asking Git which remote URLs are actually configured.
The command
git remote -vThis shows each configured remote and the URL used for fetch and push.
Typical output:
origin [email protected]:yourname/project.git (fetch)
origin [email protected]:yourname/project.git (push)
upstream [email protected]:org/project.git (fetch)
upstream [email protected]:org/project.git (push)That alone can explain a lot of “Git is acting weird” moments.
Problems it catches quickly
This command is especially useful when:
- you cloned your fork but expected the upstream repo
originpoints to HTTPS when you thought it was SSH- push and fetch URLs differ
- a repo still points to an old organization path
Without checking the remote URLs directly, developers often waste time debugging credentials, branches, or CI while the actual issue is just “wrong remote.”
A practical recovery flow
If the remote is wrong:
git remote set-url origin [email protected]:correct-owner/project.git
git remote -vThat second command matters. It confirms the fix instead of assuming it worked.
If you need both your fork and the canonical repo:
git remote add upstream [email protected]:org/project.git
git remote -vNow you can fetch from upstream and push to your fork intentionally.
Why this matters so much on teams
Fork-based workflows, company repo migrations, and mixed HTTPS/SSH setups create more remote drift than people admit. The repo name in your file tree does not prove anything about where push and fetch traffic are really going.
git remote -v is the cheap truth check.
Final recommendation
When Git starts behaving like it belongs to a different project than the one in your head, run git remote -v before you blame auth, branches, or GitHub itself. Wrong remotes are common, quiet, and expensive to overlook.