Managing Git Remotes: Why “Origin Already Exists” Isn’t a Bug

You create a new GitHub repository.

You copy the helpful command from GitHub:

git remote add origin git@github.com:your-name/your-repo.git

And Git answers, rather firmly:

fatal: remote origin already exists.

At first glance, this feels like Git being difficult for no reason.

But this error is actually useful. It means your local repository already has a remote called origin. Git is not refusing to work. It is telling you:

“I already have a remote with that name. Please decide whether you want to use it, change it, rename it, or remove it.”

Let’s unpack what origin means, why this error happens, and how to manage Git remotes without turning your repository into a small haunted forest.

fatal: remote origin already exists.

Cause: Git already has a remote named origin saved in this repository — usually from a git clone, an earlier manual git remote add, or copying an existing project folder — and refuses to silently overwrite it when you run git remote add origin <url> again.

Fix: Check what origin currently points to with git remote -v. If it is wrong, update it in place with git remote set-url origin <url> instead of running remote add again. See the options below for the full decision process.

What is origin in Git?

In Git, a remote is a saved shortcut to another copy of your repository.

Usually, that other copy lives on GitHub, GitLab, Bitbucket, or a private Git server.

The name origin is only a convention. It is not magic. It is simply the default name Git commonly uses for the main remote repository.

For example, this command:

git remote add origin git@github.com:elena/my-project.git

means:

“Git, please remember this remote repository URL and call it origin.”

After that, you can write:

git push origin main

Instead of typing the full GitHub URL every time.

So origin is a nickname.

A very common nickname, yes. But still just a nickname.

Why does “remote origin already exists” happen?

The error happens when you try to add a remote named origin, but your repository already has one.

For example:

git remote add origin git@github.com:your-name/new-repo.git

Git checks its remote list and finds that origin already exists.

So it refuses to overwrite it silently.

That is good behaviour. Imagine if Git quietly replaced your production remote with a test repository URL. Chaos. Coffee everywhere.

You usually see this error when:

• you cloned the repository from GitHub, so origin was added automatically;
• you already added an origin earlier;
• you copied a project folder from somewhere else;
• you changed GitHub repositories and forgot the old remote was still attached;
• you are turning a local project into a GitHub repository and repeated the setup command.

Check your current Git remotes

Before changing anything, inspect what Git already knows.

Run:

git remote -v

You might see something like this:

origin  git@github.com:old-name/old-repo.git (fetch)
origin  git@github.com:old-name/old-repo.git (push)

The fetch URL is used when you pull or fetch changes.

The push URL is used when you push your commits.

Most of the time, the fetch and push URLs are the same.

If the remote is correct, you do not need to add it again.

You can simply push:

git push -u origin main

Or, if your branch is called master:

git push -u origin master

The -u flag sets the upstream branch, so future pushes can usually be shortened to:

git push

Option 1: Keep the existing origin

Sometimes the error is harmless.

You run:

git remote -v

And the URL is already the right one:

origin  git@github.com:your-name/your-repo.git (fetch)
origin  git@github.com:your-name/your-repo.git (push)

In that case, do nothing.

Just push your code:

git push -u origin main

Git was not asking you to fix anything. It was only saying, “This remote already exists.”

Option 2: Change the origin URL

If origin exists but points to the wrong repository, update it.

Use:

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

Then check it:

git remote -v

You should now see:

origin  git@github.com:your-name/new-repo.git (fetch)
origin  git@github.com:your-name/new-repo.git (push)

This is usually the best fix for:

fatal: remote origin already exists.

Especially when you created a new GitHub repository and want your local project to point to it.

Option 3: Remove origin and add it again

You can also delete the old remote and add a new one.

git remote remove origin

Then add the new origin:

git remote add origin git@github.com:your-name/new-repo.git

Check it:

git remote -v

This works perfectly well.

However, I usually prefer set-url when I only want to change the URL. It is more direct and communicates the intention clearly:

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

Use remove when you really want to delete the remote entry.

Use set-url when you want to edit it.

Option 4: Rename the existing origin

Sometimes you do not want to delete the old remote.

For example, you might have:

• the original project repository;
• your fork;
• a private backup repository;
• a deployment repository.

In that case, you can rename the old remote instead.

git remote rename origin upstream

Now your old origin becomes upstream.

Then you can add a new origin:

git remote add origin git@github.com:your-name/your-fork.git

Check the result:

git remote -v

You might see:

origin    git@github.com:your-name/your-fork.git (fetch)
origin    git@github.com:your-name/your-fork.git (push)
upstream  git@github.com:original-owner/original-project.git (fetch)
upstream  git@github.com:original-owner/original-project.git (push)

This is a common open-source workflow.

Your origin points to your fork.

Your upstream points to the original project.

Then you can pull updates from the original project like this:

git fetch upstream

And push your own work to your fork:

git push origin main