Fix 'fatal: remote origin already exists' When Adding a Git Remote

The Error

You run git remote add origin <url> and Git stops you dead:

fatal: remote origin already exists.

Nine times out of ten, this hits when you're pointing an existing repo at a new host — after migrating from GitHub to GitLab, forking someone's project, or cloning a repo and trying to rewire it to your own account.

Why This Happens

Git stores remotes in .git/config. Once a remote named origin is registered there — either from a previous git remote add or automatically from git clone — Git refuses to create another one with the same name. It treats the second call as a conflict, not an update.

Common triggers:

You cloned a repo, then tried to add origin again with a different URL.
You ran git remote add origin twice in the same repo.
A setup script didn't check whether origin already existed before adding it.
You migrated from GitHub to GitLab (or vice versa) and used add instead of set-url.

Fix 1: Update the Remote URL (Quickest Fix)

Already have an origin but it points somewhere wrong? Use set-url — not add:

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

For SSH:

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

Done. The URL is replaced. Nothing else changes — branches, commits, local config all stay intact.

Fix 2: Remove Then Re-add

Want a clean slate? Remove the remote first, then add it fresh:

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

Important: Removing a remote doesn't touch your local commits or branches. It only wipes the entry from .git/config. Your work is safe.

Fix 3: Rename the Old Remote, Keep Both

Migrating repos and still need the old remote around for a while? Rename it instead of deleting it:

git remote rename origin old-origin
git remote add origin https://github.com/your-username/new-repo.git

Now you have two remotes — old-origin pointing at the previous host, and origin pointing at the new one. Pull from the old, push to the new. Handy during a migration window.

Verify the Fix

Run this to see all configured remotes and their URLs:

git remote -v

After a clean update, you'll see:

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

If you went the rename route, both remotes show up:

old-origin  https://gitlab.com/your-username/old-repo.git (fetch)
old-origin  https://gitlab.com/your-username/old-repo.git (push)
origin      https://github.com/your-username/new-repo.git (fetch)
origin      https://github.com/your-username/new-repo.git (push)

Then confirm the remote is actually reachable:

git fetch origin

No errors? You're good. An empty output is also fine — it just means there's nothing new to fetch.

Inspect the Raw Config

Curious what's actually on disk? Open .git/config directly:

cat .git/config

A typical remote entry looks like this:

[remote "origin"]
    url = https://github.com/your-username/your-repo.git
    fetch = +refs/heads/*:refs/remotes/origin/*

You can edit this file by hand as a last resort. But the git remote commands are safer — one typo in the config file can break your entire remote setup.

Prevent It in Scripts

Writing a bootstrap script? Add a check before blindly calling git remote add:

REMOTE_URL="https://github.com/your-username/your-repo.git"

if git remote get-url origin >/dev/null 2>&1; then
  git remote set-url origin "$REMOTE_URL"
else
  git remote add origin "$REMOTE_URL"
fi

If origin exists, update it. If not, create it. This pattern handles both cases and never throws the fatal error — regardless of how many times the script runs.

Quick Reference

Wrong URL → right URL: git remote set-url origin <new-url>
Start fresh: git remote remove origin then git remote add origin <url>
Keep old, add new: git remote rename origin old-origin then git remote add origin <url>
Check current state: git remote -v