Git: 'remote origin already exists' - How to Fix It

fatal: remote origin already exists. means you ran git remote add origin <url> but a remote named origin is already configured in this repository. You do not need to add it again. To point origin at a different URL, run git remote set-url origin <new-url>. To inspect what is already set, run git remote -v.

That one line is the whole fix for most people. The rest of this article explains why the message shows up, how to check the current remote, and the handful of cases where you genuinely want to remove and re-add instead of updating.

The exact error

When you try to add a remote that already exists, Git prints this and stops:

fatal: remote origin already exists.

origin is just a name (a label) for a remote URL. By convention it is the name Git gives the place you cloned from, or the first remote you add by hand. The error is not saying anything is broken. It is saying the label is already taken, so Git refuses to silently clobber it.

Why this happens

You usually hit this in one of three situations:

• You cloned the repo, then tried to add origin again. Cloning sets origin for you automatically, so a later git remote add origin ... collides with it. This is the most common cause: people follow GitHub's "push an existing repository" snippet on a repo they actually cloned.
• You ran git remote add origin ... twice. Maybe a tutorial step got repeated, or you pasted the same block of setup commands two times.
• You initialised with git init, added origin, and are now setting up a new GitHub repo for the same folder. This is the same flow as adding Git to an existing folder, where you set its remote with git remote add for the first time; the old origin is still there pointing at the previous URL.

In every case the answer is the same: the remote already exists, so you update it or replace it rather than adding it.

Step 1: see what is already set

Before you change anything, look at the current remotes. This is the single most useful command for this error:

git remote -v

You will get something like this:

origin  https://github.com/you/your-repo.git (fetch)
origin  https://github.com/you/your-repo.git (push)

Now you can decide. If that URL is already the one you want, you are done, there was never anything to fix. If it points at the wrong place (an old repo, the wrong account, HTTPS when you wanted SSH), update it in Step 2.

Step 2: update the existing remote (the usual fix)

Most of the time you do not want a different remote, you want origin to point at the right URL. Use git remote set-url:

git remote set-url origin https://github.com/you/your-repo.git

Or, if you are switching to an SSH remote (in which case you need to add an SSH key to your account first, or the SSH remote will not authenticate):

git remote set-url origin git@github.com:you/your-repo.git

Confirm it took:

git remote -v

set-url rewrites the URL in place without touching anything else (branch tracking, fetch refspecs). It is the clean way to change where origin points. If you are weighing up which URL style to use, I compare them in Git SSH vs HTTPS remotes; the short version is SSH for machines you control, HTTPS for everywhere else. If you are switching transport because HTTPS suddenly stopped accepting your password, that is a separate change GitHub made, and I cover why password pushes stopped working there too.

Step 3: remove and re-add (when you actually need to)

Occasionally set-url is not enough. If the remote is misconfigured beyond just the URL, or you want a genuinely fresh definition, remove it and add it back:

git remote remove origin
git remote add origin https://github.com/you/your-repo.git
git remote -v

git remote remove origin (the older spelling git remote rm origin still works) deletes the remote and its tracking configuration. The following git remote add origin ... recreates it cleanly. Because the name is now free, the add succeeds instead of erroring.

You only need this path when the remote's config is genuinely wrong, not just its URL. For a simple "wrong address" fix, set-url from Step 2 is less disruptive.

set-url vs remove-and-re-add: which one?

That last row is worth calling out. If you are working with a fork, you do not fight over the origin name at all: you add the original repo under a second name, conventionally upstream. That is exactly the setup I walk through in syncing a fork with its upstream repo, and the difference between the two is covered in fork vs clone.

A common follow-on: pushing for the first time

Once origin points where you want, the next thing people try is a push, and that can surface a different message:

git push -u origin main

If Git complains that the current branch has no upstream, that is a separate, expected step on a first push and not the same problem; I cover it in the no upstream branch fix. The -u flag is what sets the tracking link so later pushes are just git push.

Verifying you are out of the woods

After applying the fix, three quick checks confirm everything is consistent:

git remote -v
git remote show origin
git branch -vv

git remote -v shows the URL is right. git remote show origin (which contacts the remote) confirms Git can actually reach it and lists the branches it knows about. git branch -vv shows which remote branch each local branch tracks. If all three line up, the remote is set correctly.

If you are still finding your feet with how remotes, branches, and the rest of Git fit together, start at my Git for beginners guide, which lays out the whole mental model. When you are ready to dig into how origin interacts with fetching, git pull vs git fetch explains what actually moves between your machine and the remote.

FAQ