Fixing Git Error: fatal: remote origin already exists

What this error means

You see this when running git remote add origin <url> but a remote named origin is already defined in the repo’s .git/config. It often happens after cloning, re-initializing, or re-running a setup script in CI/CD.

Quickstart

• Inspect existing remotes: git remote -v
• Want to change origin URL: git remote set-url origin git@server:org/repo.git
• Want a new remote without touching origin: git remote add upstream git@server:org/repo.git
• Want to replace origin: git remote remove origin && git remote add origin git@server:org/repo.git
• Verify: git remote -v and git fetch origin

Minimal working example (MWE)

# Create a new repo and provoke the error
mkdir demo-remote-origin && cd demo-remote-origin
git init

git remote add origin git@server:org/old.git
# Adding origin again triggers the error
if git remote add origin git@server:org/new.git; then
  echo "Unexpected: no error"
else
  echo "Got expected error: fatal: remote origin already exists"
fi

# Fix by updating the URL instead of adding a new remote
git remote set-url origin git@server:org/new.git

echo "Remotes after fix:"
git remote -v

Expected output after fix includes:

• origin git@server:org/new.git (fetch)
• origin git@server:org/new.git (push)

Step-by-step resolution

1. Check current state

• git remote -v to list existing remotes and URLs
• git remote get-url origin and git remote get-url --push origin to see fetch/push URLs

1. Decide your intent

• Replace the origin URL? Use set-url.
• Keep existing origin and add another remote (e.g., upstream)? Use add.
• Rename origin to something else then create a new origin? Use rename + add.
• Remove and recreate origin? Use remove + add (be mindful of tracking branches).

1. Apply the fix

• Change URL in place:
  • git remote set-url origin git@server:org/repo.git
• Add a second remote (fork/upstream workflow):
  • git remote add upstream git@server:org/upstream.git
• Rename origin then add new origin:
  • git remote rename origin old-origin
  • git remote add origin git@server:org/new.git
• Remove and add:
  • git remote remove origin
  • git remote add origin git@server:org/new.git

1. Verify and fetch

• git remote -v
• git fetch --prune origin

1. Restore/set branch tracking if needed

• If tracking was lost (after remove/add), re-set upstream:
  • git branch -vv to inspect
  • git push -u origin main (replace main with your branch name)

CI/CD-safe pattern (idempotent)

Use a conditional so re-running the job doesn’t fail:

set -euo pipefail
URL="git@server:org/repo.git"
if git remote get-url origin >/dev/null 2>&1; then
  git remote set-url origin "$URL"
else
  git remote add origin "$URL"
fi

If you only want to set the push URL (keeping fetch URL intact):

git remote set-url --push origin git@server:org/repo-mirror.git

Which approach should I choose?

Common pitfalls

• Losing tracking configuration
  • Removing origin can orphan branch tracking (branch.remote/branch.merge). Fix with git push -u origin <branch> or git branch --set-upstream-to=origin/<branch>.
• Wrong protocol/credentials
  • SSH vs HTTPS mismatches cause auth failures. Ensure the URL matches your auth method and keys/tokens are loaded.
• CI scripts that always run git remote add origin ...
  • Switch to the idempotent pattern using git remote get-url guard.
• Confusing fetch and push URLs
  • git remote set-url origin <url> sets both. Use --push or --add --push for push-only changes or multiple push URLs.
• Typos in remote names
  • origin vs orgin silently creates an extra remote. Always inspect with git remote -v.
• Editing .git/config manually
  • Safe but easy to break formatting. Prefer git remote and git config commands.

Performance notes

• All git remote operations shown are local metadata updates and are effectively instantaneous.
• git fetch after changing URLs incurs network I/O; use --prune to drop deleted remote refs.
• Using set-url or rename avoids reconfiguring branch tracking and prevents unnecessary network operations compared to remove+add.
• Adding/removing remotes does not duplicate objects; repository size is unaffected until you fetch.
• In large monorepos, avoid unnecessary git fetch --all. Target only the remote you changed: git fetch origin.

Troubleshooting checklist

• git remote -v — confirm the remotes and URLs
• git remote get-url origin — verify the effective fetch URL
• git remote get-url --push origin — verify push URL(s)
• git branch -vv — confirm upstream tracking
• git ls-remote origin — check connectivity and permissions

FAQ

• What is “origin”?

  • The default name for the primary remote created by clone or initial setup.

• How do I see if origin exists?

  • git remote lists remotes. git remote -v shows their URLs.

• Can I have multiple remotes?

  • Yes. Common names are origin (your fork) and upstream (the source repository).

• How do I fix this error in a script?

  • Guard with git remote get-url origin and then set-url or add accordingly (see CI/CD-safe pattern).

• How do I change only the push URL?

  • git remote set-url --push origin <url>; use git remote get-url --push origin to verify.

• Do I need to re-clone after changing origin?

  • No. Update the URL and fetch; re-cloning is unnecessary in almost all cases.