Fix: fatal: remote origin already exists

The Error

You run git remote add origin to connect your local repository to a remote, and Git throws:

fatal: remote origin already exists.

The full command usually looks like this:

git remote add origin https://github.com/user/repo.git

Or with SSH:

git remote add origin git@github.com:user/repo.git

Either way, Git refuses to add the remote. The error appears in the terminal, in VS Code’s Git integration, in JetBrains IDEs, and in any other tool that wraps Git under the hood.

Why This Happens

Git remotes are named references to remote repository URLs. When you run git remote add origin <url>, Git tries to create a new remote called origin. If a remote with that name already exists in your repository’s configuration, Git stops and throws the error.

Here are the most common scenarios that lead to this:

You already initialized the remote. You ran git remote add origin earlier in the project, or the repo was cloned from a remote (cloning automatically sets origin to the source URL). Running the command a second time fails because the name is taken.

You cloned the repo. When you git clone a repository, Git automatically creates a remote named origin pointing to the URL you cloned from. If you then try to add origin again — perhaps to point it at a different URL — you get the error.

You re-initialized the repo. You ran git init in a directory that already had a .git folder. The git init command does not remove existing remotes. Your old origin remote survives the reinitialization. If you’re troubleshooting Git not recognizing your repository, be aware that re-running git init does not reset remotes.

You’re following a tutorial. Many tutorials include git remote add origin as a step. If you’ve already done it once — or if you’re restarting the tutorial — the second attempt fails.

A GUI tool or IDE set it up. Tools like GitHub Desktop, VS Code, and JetBrains IDEs often configure remotes automatically when you create or open a project. You may not realize origin already exists.

Fix 1: Update the Existing Remote URL

If origin already exists and you want to change where it points, use git remote set-url instead of git remote add:

git remote set-url origin https://github.com/user/new-repo.git

This overwrites the existing URL without removing and re-adding the remote. It preserves any tracking branch configuration tied to origin.

Verify the change:

git remote -v

You should see:

origin  https://github.com/user/new-repo.git (fetch)
origin  https://github.com/user/new-repo.git (push)

This is the recommended approach in most cases. It is a single command, it does not disrupt your branch tracking, and it avoids the brief window where no remote exists at all.

Pro Tip: git remote set-url also works for switching between HTTPS and SSH URLs. If you need to switch from HTTPS to SSH (for example, to stop entering your password on every push), run:

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

Conversely, switch from SSH to HTTPS:

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

If you run into authentication issues after switching to SSH, check your SSH key configuration.

Fix 2: Remove the Remote and Re-Add It

If you want a clean slate — or if the existing remote has corrupted configuration — remove it first, then add it fresh:

git remote remove origin
git remote add origin https://github.com/user/repo.git

The older syntax git remote rm origin also works and does the same thing:

git remote rm origin
git remote add origin https://github.com/user/repo.git

After adding, verify:

git remote -v

When to use this over set-url: Use this approach when you want to reset all configuration associated with the remote, including custom fetch refspecs, push URLs, or per-remote settings. set-url only changes the URL; remove + add wipes everything and starts fresh.

Note: Removing a remote also removes all remote-tracking branches associated with it (origin/main, origin/develop, etc.). They will be recreated the next time you git fetch, but any local configuration referencing them (such as branch tracking) will need to be set up again.

After re-adding the remote, set your branch to track the remote branch:

git branch --set-upstream-to=origin/main main

Or push with the -u flag to set tracking automatically:

git push -u origin main

If the push is rejected, you may have a non-fast-forward issue that needs resolving separately.

Fix 3: Inspect Your Remotes First

Before changing anything, check what remotes you currently have:

git remote -v

This shows all configured remotes with their fetch and push URLs:

origin  https://github.com/user/old-repo.git (fetch)
origin  https://github.com/user/old-repo.git (push)

You might discover that origin already points to the correct URL. In that case, no fix is needed — you can skip the git remote add step entirely and move on to pushing or pulling.

You can also inspect a specific remote in detail:

git remote show origin

This displays the remote URL, the HEAD branch, tracked branches, and the local branches configured for git pull and git push. It is useful for diagnosing mismatched configurations.

If you want to see the raw Git configuration for remotes, check your .git/config file:

cat .git/config

Look for sections like:

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

You can manually edit this file to change or remove remotes, but using git remote commands is safer and less error-prone.

Fix 4: Use a Different Remote Name

You are not limited to the name origin. If you need to add a second remote — for example, to push to a different hosting service — use a different name:

git remote add github https://github.com/user/repo.git
git remote add gitlab https://gitlab.com/user/repo.git
git remote add bitbucket https://bitbucket.org/user/repo.git

Then push to a specific remote by name:

git push github main
git push gitlab main

This is common when you mirror a repository across multiple platforms or when you want to deploy to different services from the same repo.

Working With Forked Repositories

When you fork a repository on GitHub, a common convention is:

• origin points to your fork
• upstream points to the original repository

If you cloned your fork, origin is already set. Add the original repo as upstream:

git remote add upstream https://github.com/original-owner/repo.git

Now you can pull changes from the original project:

git fetch upstream
git merge upstream/main

Or rebase on top of upstream changes:

git fetch upstream
git rebase upstream/main

If you accidentally tried to add the original repo as origin (which is already taken by your fork), that is when you hit the “remote origin already exists” error. The fix is to use upstream as the remote name instead.

To verify your setup:

git remote -v

Expected output for a forked repo:

origin    https://github.com/your-user/repo.git (fetch)
origin    https://github.com/your-user/repo.git (push)
upstream  https://github.com/original-owner/repo.git (fetch)
upstream  https://github.com/original-owner/repo.git (push)

Common Mistake: Don’t set origin to the upstream (original) repository if you forked it. You won’t have push access to the original repo in most cases. Keep origin pointed at your fork and use upstream for the source repository. Pushing to a remote you don’t have write access to results in permission errors or rejected pushes.

Fix 5: Handle Re-Initialized Repositories

If you ran git init in a folder that already had a .git directory, your existing remotes survive. Git prints:

Reinitialized existing Git repository in /path/to/repo/.git/

This message tells you the repository was not created fresh. All previous configuration, including remotes, branches, and commit history, remains intact.

If your intent was to start completely fresh, you have two options.

Option A: Remove the .git directory and reinitialize:

rm -rf .git
git init
git remote add origin https://github.com/user/repo.git

Warning: This permanently deletes all Git history, branches, stashes, and configuration. Only do this if you genuinely want to start from scratch.

Option B: Just update the remote:

git remote set-url origin https://github.com/user/new-repo.git

This keeps your history and branches intact while pointing origin at a new location.

If you accidentally deleted your .git folder and lost your repository, see fixing a missing .git directory for recovery steps.

Fix 6: Switch Between HTTPS and SSH

A common reason for re-adding origin is switching the protocol. Maybe you set up the repo with HTTPS but now want SSH (or vice versa).

Check the current URL:

git remote -v

If you see an HTTPS URL:

origin  https://github.com/user/repo.git (fetch)
origin  https://github.com/user/repo.git (push)

Switch to SSH:

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

If you see an SSH URL and want HTTPS:

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

HTTPS vs SSH: When to Use Which

Use SSH when:

• You have SSH keys set up and want passwordless pushes
• You work on a machine where you can store keys securely
• You’re tired of entering credentials or dealing with token expiration

Use HTTPS when:

• You’re behind a corporate firewall that blocks SSH (port 22)
• You prefer using a personal access token (PAT) for authentication
• You’re on a shared or temporary machine where storing SSH keys is not ideal

For GitHub specifically, the URL formats are:

For GitLab:

For Bitbucket:

Fix 7: Fix the Error in VS Code, JetBrains, or Other IDEs

If you encounter this error in an IDE rather than the terminal, the underlying cause and fix are the same. The IDE is running git remote add origin behind the scenes, and it fails because origin already exists.

VS Code:

1. Open the terminal in VS Code (Ctrl+`` or Cmd+`` on macOS).
2. Run git remote -v to see current remotes.
3. Use git remote set-url origin <new-url> to update.

Alternatively, edit .git/config directly — VS Code can open it like any other file.

JetBrains (IntelliJ, WebStorm, PyCharm, etc.):

1. Go to Git > Manage Remotes (or VCS > Git > Remotes in older versions).
2. You’ll see the existing origin remote listed.
3. Click the pencil icon to edit the URL, or the minus icon to remove it.

GitHub Desktop:

1. Go to Repository > Repository Settings.
2. The primary remote URL is shown under Remote.
3. Change the URL and click Save.

In all cases, the fix is the same: update the existing origin URL rather than trying to add a new one.

Fix 8: Handle CI/CD Pipeline Errors

This error can appear in CI/CD pipelines (GitHub Actions, GitLab CI, Jenkins, etc.) when a script tries to add a remote that already exists. Pipelines typically clone the repo, which sets origin automatically.

Make your pipeline script idempotent by checking if the remote exists before adding it:

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

Or use a simpler one-liner that removes first (ignoring errors if it does not exist) and then adds:

git remote remove origin 2>/dev/null; git remote add origin "$REPO_URL"

This pattern prevents the error from breaking your pipeline regardless of the repository state.

Still Not Working?

If the fixes above did not resolve your issue, try these less obvious solutions:

Check for a corrupted .git/config file. Open .git/config in a text editor and look for duplicate [remote "origin"] sections or malformed entries. Remove duplicates manually and save. If the file is severely corrupted, you may need to clone the repo fresh.

Check for nested Git repositories. If you have a .git directory inside another Git repository’s subdirectory, you may be running commands in the wrong context. Run git rev-parse --show-toplevel to confirm which repository root you’re operating in.

Check if you’re in a detached HEAD state. While a detached HEAD does not directly cause the “remote origin already exists” error, it can create confusion about which branch and remote you’re working with. Make sure you’re on the correct branch before modifying remotes.

Verify file system permissions. On Linux/macOS, if the .git/config file is read-only or owned by a different user, Git may fail in unexpected ways. Check permissions with ls -la .git/config and fix with chmod or chown if needed.

Re-clone as a last resort. If nothing else works and your remote configuration is completely mangled, the simplest fix is to re-clone:

cd ..
mv repo repo-backup
git clone https://github.com/user/repo.git

Copy any uncommitted work from repo-backup into the fresh clone. This gives you a clean .git directory with properly configured remotes.

Check for Git LFS issues. If you’re using Git LFS and seeing additional errors alongside the remote issue, the remote configuration problem might be preventing LFS from communicating with the server. Fix the remote first, then address any LFS-related errors separately.