Git

How to Fix "fatal: remote origin already exists" When Adding Remote

4 min read by DebuggedIt

Quick answer

You try to connect your local repo to a GitHub remote and Git tells you the remote already exists instead of adding it. This means a remote named origin is...

You try to connect your local repo to a GitHub remote and Git tells you the remote already exists instead of adding it. This means a remote named origin is already configured — you just need to update it instead of creating a new one.

The Problem

Following a typical "push an existing repo" setup, you run:

$ git remote add origin https://github.com/youruser/yourrepo.git
fatal: remote origin already exists.

This happens even on repos you just created locally, especially if you initialized with a hosting platform's CLI or template that pre-configures a remote for you.

Why It Happens

Git only allows one remote per name — origin is just a conventional name, not a reserved keyword, and it can only point to one URL at a time. This error shows up when:

  • You cloned the repo (cloning automatically creates an origin remote pointing at the source URL) and then tried to add it again manually.
  • A previous setup step, template, or CI tool already configured origin for you.
  • You're re-running setup instructions from a README or tutorial on a repo that's already partially configured.
  • You're trying to point the same local repo at a different GitHub repository (e.g., after transferring ownership or renaming) and forgot the old remote is still there.

The Fix

First, check what origin currently points to:

git remote -v
origin  https://github.com/olduser/oldrepo.git (fetch)
origin  https://github.com/olduser/oldrepo.git (push)

If that URL is wrong or outdated, update it in place instead of adding a new remote:

git remote set-url origin https://github.com/youruser/yourrepo.git

Verify the change took effect:

git remote -v
origin  https://github.com/youruser/yourrepo.git (fetch)
origin  https://github.com/youruser/yourrepo.git (push)

If you'd rather remove it and re-add cleanly instead:

git remote remove origin
git remote add origin https://github.com/youruser/yourrepo.git

If you actually need multiple remotes pointing to different places (for example, pushing to both GitHub and GitLab, or keeping a fork's upstream), give the second one a different name rather than reusing origin:

git remote add upstream https://github.com/originaluser/originalrepo.git

You can now fetch and merge from either independently:

git fetch upstream
git merge upstream/main

Still Not Working?

If git remote set-url succeeds but pushes still go to the wrong place, check whether you have a push-specific URL override configured separately from the fetch URL:

git config --get remote.origin.pushurl

If that returns a value, it's overriding the push destination independently — update or remove it explicitly:

git config --unset remote.origin.pushurl

It's also worth checking exactly where Git is reading its remote configuration from, since remotes are stored per-repository in .git/config, not globally. If you're working across multiple clones of the same project (a common setup when you have both a personal fork and a work copy checked out separately), it's easy to assume you're editing one repo's remotes when you're actually in another directory entirely:

pwd
cat .git/config

Reading the raw config file directly shows you every remote section Git has stored, which can be clearer than parsing git remote -v output when you're troubleshooting multiple remotes or unusual configurations, such as a remote with a custom fetch refspec.

If you manage a lot of repositories and frequently run into this error while following setup scripts or onboarding docs, consider making remote setup idempotent in your own scripts by checking first instead of assuming origin is unset:

git remote get-url origin 2>/dev/null && \
  git remote set-url origin https://github.com/youruser/yourrepo.git || \
  git remote add origin https://github.com/youruser/yourrepo.git

This one-liner checks whether origin already exists and updates it if so, or adds it fresh if not — useful for setup scripts that need to run safely whether or not the remote is already configured.

Finally, if you're using SSH instead of HTTPS and the remote URL format looks different from what you expected, make sure you're not mixing the two protocols by accident. An HTTPS remote and an SSH remote for the same GitHub repository look nothing alike, and copy-pasting the wrong one from a browser tab is a common source of confusion when updating an existing origin:

git remote set-url origin git@github.com:youruser/yourrepo.git

Confirm authentication works correctly with the new SSH remote before pushing anything important:

ssh -T git@github.com

A successful response confirms your SSH key is registered with GitHub and the remote is reachable, which rules out authentication as a separate problem on top of the remote configuration itself.

You might also like