By Kedar Salunkhe | Last Updated: March 2026
You just created a new repository on GitHub, followed the setup instructions, and typed the command to connect your local project to it:
git remote add origin https://github.com/USERNAME/REPO.gitAnd then this comes back:
error: remote origin already exists.It’s a one-liner. No stack trace, no verbose output, no helpful suggestion about what to do next. Just a flat rejection and a blinking cursor.
If you’ve landed here, you’re probably wondering one of a few things. Did you already connect this repository to something? Did a previous command set something up without you realizing? Is it safe to overwrite it? And most importantly — what’s the fastest way to get past this and back to what you were actually trying to do?
Here’s the honest answer: this error is one of the most harmless in all of Git. It’s not a sign that anything is broken. It just means Git already has a remote named “origin” configured for this repository, and you tried to add another one with the same name. Git doesn’t allow two remotes with the same name, so it stops you.
The fix is almost always one command. But which command depends on what you’re actually trying to accomplish — and that’s what this guide is for. It covers every scenario where this error appears, explains exactly what’s happening in each one, and gives you the precise fix for your specific situation.
Let’s get into it.
Remote Origin Already Exists Error – 5 Quick Fixes (Step-by-Step Guide)
What Is the Remote Origin Already Exists Error?
The full error reads:
error: remote origin already exists.It appears whenever you run:
git remote add origin URLand Git finds that a remote named “origin” is already configured for the current repository.
Here’s the context that makes this make sense. In Git, a remote is a named reference to a repository hosted somewhere else — on GitHub, GitLab, Bitbucket, or any other server. The name “origin” is just a convention. It’s the default name Git uses for the primary remote, and the name GitHub suggests in its repository setup instructions. But it’s not special — it’s just a name, and Git stores it in your repository’s configuration file alongside its URL.
When you run git remote add origin URL, you’re telling Git: “Add a new remote entry, name it ‘origin’, and point it at this URL.” If a remote named “origin” already exists in that configuration file, Git refuses to create a duplicate. That’s the entirety of this error.
You’ll see it most commonly in these situations:
You’re following GitHub’s “push an existing repository” instructions for a project you already set up as a Git repository earlier, and your initialization already created a remote.
You cloned a repository (which automatically sets up origin pointing at the source), then tried to add origin again.
You initialized a repository, set up the remote manually, got distracted, and then ran the setup commands again later without remembering you’d already done it.
You copied a project directory from another location that already had a .git folder with remotes configured.
You’re working on a shared machine or a VM where someone else already initialized the repository.
Regardless of which scenario applies, the fix is the same family of commands. Let’s look at what those are.
Why Does This Error Happen?
Before jumping into fixes, a quick look at the underlying mechanics helps you understand which fix to apply.
Every Git repository stores its configuration in a file called .git/config inside the project directory. When you add a remote, Git writes an entry to this file. You can look at it directly:
cat .git/configThe relevant part looks like this:
[remote "origin"]
url = https://github.com/USERNAME/REPO.git
fetch = +refs/heads/:refs/remotes/origin/This is what a configured remote looks like. The name in quotes (“origin”) is what Git checks against when you try to add a new remote. If a [remote “origin”] block already exists, the git remote add origin command fails immediately with the error you saw.
There are five distinct situations that lead to this error, each requiring a slightly different response:
Situation 1 — The existing origin points to the right place and you just ran git remote add again by mistake. You don’t actually need to do anything.
Situation 2 — The existing origin points to the wrong URL and you need to update it.
Situation 3 — You want to completely replace the origin remote with a new one.
Situation 4 — You want to add a second remote without touching origin.
Situation 5 — You want to remove origin entirely and start fresh.
Let’s work through the fix for each of these.
Fix 1 — Check What’s Already There (Do This First, Every Time)
Before applying any fix, spend ten seconds checking what’s already configured. This one step will tell you whether you need to do anything at all, or which of the other fixes applies.
git remote -vThis command lists all configured remotes and their URLs. The output looks like this:
origin https://github.com/USERNAME/REPO.git (fetch)
origin https://github.com/USERNAME/REPO.git (push)Read this output and ask yourself three questions:
Is “origin” listed? If yes, a remote named origin already exists — which is exactly what the error is telling you.
Does the URL match what you intended to add? If it already points to the right repository, you don’t need to do anything else. The remote is already set up correctly. Skip all remaining fixes and proceed with your git push, git pull, or whatever you were trying to do.
Does the URL point somewhere different? If origin exists but points to the wrong repository — maybe an old project, a different fork, or a placeholder — you need Fix 2 or Fix 3.
This check takes ten seconds and resolves the confusion for the majority of people who hit this error. They ran git remote add origin again when the remote was already correctly configured from a prior step, and there’s nothing left to fix.
If git remote -v shows nothing (no remotes listed at all), then the error message was misleading and something else is going on. Try running git remote add origin URL again — the error shouldn’t reappear.
If git remote -v shows origin pointing to the right URL, run your git push directly:
git push -u origin main
You’re already connected to the right remote. The error was just telling you the connection already exists.
Fix 2 — Update the Existing Origin URL (The Most Common Fix)
This is the fix for the most common real scenario: origin already exists and points somewhere, but you need it to point somewhere different. Maybe you initialized a repository and set origin to a test URL, maybe you’re repurposing a project directory, or maybe the URL changed because the repository was renamed or moved.
The command is git remote set-url. It changes the URL of an existing remote without removing and re-adding it:
git remote set-url origin https://github.com/USERNAME/REPO.gitReplace the URL with the correct URL for your repository.
For SSH instead of HTTPS:
git remote set-url origin git@github.com:USERNAME/REPO.gitStep 1 — Verify the current URL
git remote -v
Note the URL that origin currently points to.
Step 2 — Set the new URL
git remote set-url origin https://github.com/NEW-USERNAME/NEW-REPO.git
Step 3 — Verify the change
git remote -v
The output should now show the new URL for both fetch and push.
Step 4 — Test the connection
For SSH, verify authentication works:
ssh -T git@github.com
For HTTPS, you can test by running a fetch:
git fetch origin
If the fetch returns without errors, the remote URL is correct and you have access.
Step 5 — Push your changes
git push -u origin main
The -u flag sets the upstream tracking relationship so future git push and git pull commands don’t need to specify the remote and branch.
If your branch is called master instead of main:
git push -u origin master
If you’re not sure what your branch is called:
git branch
This lists your local branches. The one with an asterisk (*) next to it is your current branch.
When Should You Use set-url vs remove + add?
Use git remote set-url when you just need to update the URL. It’s faster, cleaner, and preserves any other configuration associated with that remote (like custom fetch refspecs or push configurations).
Use remove followed by add (Fix 3) when you want a completely clean slate for the origin remote — for example, if you want to change both the name convention and URL, or if there’s something unusual in the existing remote configuration that you’d rather start fresh on.
Fix 3 — Remove and Re-Add the Origin Remote
This fix is for when you want to completely replace the origin remote — remove the existing entry entirely and add a fresh one. It gives you a clean slate and is the right approach when the existing remote configuration feels messy or when you want to be certain nothing old is carried over.
Step 1 — Remove the existing origin remote
git remote remove origin
This deletes the [remote “origin”] block from .git/config entirely. No data is lost — it just removes the pointer to the remote repository.
Alternative syntax (both do the same thing):
git remote rm origin
Step 2 — Verify it’s gone
git remote -v
The output should be blank. No remotes are configured.
Step 3 — Add the remote fresh
git remote add origin https://github.com/USERNAME/REPO.git
Or with SSH:
git remote add origin git@github.com:USERNAME/REPO.git
Step 4 — Verify the new remote
git remote -v
Expected output:
origin https://github.com/USERNAME/REPO.git (fetch)
origin https://github.com/USERNAME/REPO.git (push)Step 5 — Push your code
git push -u origin main
If this is the first push to a new GitHub repository, you’ll see output showing Git creating the remote branch and setting up tracking. Subsequent pushes won’t need the -u flag.
A Note on Upstream Tracking
When you remove and re-add a remote, any upstream tracking relationships your local branches had with that remote are lost. If you had previously set your main branch to track origin/main, you’ll need to re-establish that:
git branch –set-upstream-to=origin/main main
Or just use -u on your next push, which sets the tracking relationship automatically:
git push -u origin main
Fix 4 — Add a Second Remote With a Different Name
Sometimes you genuinely need two remotes. The most common scenarios are:
You have a fork of a repository and you want origin to point to your fork while also keeping a connection to the original repository (conventionally named upstream).
You want to push to both GitHub and GitLab simultaneously.
You’re migrating a repository from one hosting platform to another and need both remotes active during the transition.
You’re pushing to a deployment server as well as a code hosting platform.
In these cases, you don’t want to overwrite or remove origin — you want to add a second remote with a different name.
Step 1 — Verify what’s already configured
git remote -v
Step 2 — Add a second remote with a different name
The name “upstream” is the convention for the original repository when you’ve forked it:
git remote add upstream https://github.com/ORIGINAL-OWNER/ORIGINAL-REPO.git
For a GitLab mirror:
git remote add gitlab https://gitlab.com/USERNAME/REPO.git
For a deployment server:
git remote add production user@deploy-server.com:/var/repos/myproject.git
You can use any name that isn’t already taken. Run git remote -v to see what names are already in use.
Step 3 — Verify both remotes
git remote -v
Output with two remotes looks like this:
origin https://github.com/YOUR-USERNAME/REPO.git (fetch)
origin https://github.com/YOUR-USERNAME/REPO.git (push)
upstream https://github.com/ORIGINAL-OWNER/REPO.git (fetch)
upstream https://github.com/ORIGINAL-OWNER/REPO.git (push)Step 4 — Fetch from the new remote
git fetch upstream
This downloads the branches from the upstream repository so you can reference them locally, merge changes from the original into your fork, etc.
Working With Multiple Remotes Day to Day
With multiple remotes, you need to specify which remote you’re pushing to or pulling from:
Push to your fork:
git push origin main
Pull the latest changes from the original repository:
git fetch upstream
git merge upstream/main
Push to GitLab at the same time as GitHub:
git push origin main
git push gitlab main
Or push to all remotes at once by setting up a push URL on origin:
git remote set-url –add –push origin https://github.com/USERNAME/REPO.git
git remote set-url –add –push origin https://gitlab.com/USERNAME/REPO.git
After adding both push URLs, git push origin pushes to both GitHub and GitLab simultaneously.
The Fork Workflow in Full
Here’s the complete fork workflow setup, which is the most common reason developers need two remotes:
Clone your fork:
git clone https://github.com/YOUR-USERNAME/REPO.git
Add the upstream (original) repository:
git remote add upstream https://github.com/ORIGINAL-OWNER/REPO.git
Verify:
git remote -v
Fetch upstream changes and merge into your local branch:
git fetch upstream
git checkout main
git merge upstream/main
Push the merged changes to your fork:
git push origin main
Fix 5 — Edit the Git Config File Directly
Every fix in this guide can also be accomplished by editing the .git/config file directly in a text editor. This is useful when you want to make multiple changes at once, when you’re dealing with unusual remote configurations that the command-line tools don’t handle cleanly, or when you’re debugging a complex setup and want to see the full picture before making changes.
This approach requires a bit more care than using the git remote commands because you’re editing a configuration file by hand — but it gives you complete visibility and control.
Step 1 — Open the config file
The file is at .git/config inside your repository directory. Make sure you’re in the repository root first:
cat .git/config
You’ll see something like this:
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = https://github.com/OLD-USERNAME/OLD-REPO.git
fetch = +refs/heads/:refs/remotes/origin/
[branch "main"]
remote = origin
merge = refs/heads/mainStep 2 — Open it in a text editor
nano ~/.git/config
Or with VS Code:
code .git/config
Or with vim:
vim .git/config
Step 3 — Make your changes
To update the URL, change the url line under [remote “origin”]:
[remote "origin"]
url = https://github.com/NEW-USERNAME/NEW-REPO.git
fetch = +refs/heads/:refs/remotes/origin/
To remove the remote entirely, delete the entire [remote "origin"] block:
[remote "origin"]
url = https://github.com/OLD-USERNAME/OLD-REPO.git
fetch = +refs/heads/:refs/remotes/origin/
Select and delete these four lines.
To add a second remote, add a new block after the existing one:
[remote "upstream"]
url = https://github.com/ORIGINAL-OWNER/ORIGINAL-REPO.git
fetch = +refs/heads/:refs/remotes/upstream/Step 4 — Save and verify
Save the file, then verify your changes took effect:
git remote -v
The output should reflect exactly what you edited in the file.
When Direct Config Editing Is Useful
While the git remote commands cover most scenarios, direct config editing is genuinely useful in these cases:
You need to set custom fetch refspecs (for example, fetching pull requests from GitHub):
[remote "origin"]
url = https://github.com/USERNAME/REPO.git
fetch = +refs/heads/:refs/remotes/origin/
fetch = +refs/pull//head:refs/remotes/origin/pr/You need to set separate fetch and push URLs for the same remote:
[remote "origin"]
url = https://github.com/USERNAME/REPO.git
fetch = +refs/heads/:refs/remotes/origin/
pushurl = git@github.com:USERNAME/REPO.gitYou’re batch-updating multiple remotes across multiple repositories using a script.
You’re troubleshooting a repository configuration issue and want to see and edit everything in one place.
Real Terminal Example — Full Diagnostic and Fix Session
Here’s a complete terminal session showing the error appearing, being diagnosed, and resolved in the most common real-world scenario: someone following GitHub’s “push an existing repository” instructions on a project that already had a remote set up.
$ mkdir my-project && cd my-project
$ git init
Initialized empty Git repository in /home/user/my-project/.git/
$ git remote add origin https://github.com/devuser/my-project.git[Remote added — first time, works fine]
$ echo "# My Project" > README.md
$ git add .
$ git commit -m "Initial commit"
[main (root-commit) a1b2c3d] Initial commit
1 file changed, 1 insertion(+)
create mode 100644 README.md
[Later, following GitHub's setup instructions again by mistake:]
$ git remote add origin https://github.com/devuser/my-project.git
error: remote origin already exists.
[Error appears — origin was already added in the first step]
$ git remote -v
origin https://github.com/devuser/my-project.git (fetch)
origin https://github.com/devuser/my-project.git (push)
[Origin already points to the correct URL — nothing to fix]
$ git push -u origin main
Enumerating objects: 3, done.
Counting objects: 100% (3/3), done.
Writing objects: 100% (3/3), 226 bytes | 226.00 KiB/s, done.
Total 3 (delta 0), reused 0 (delta 0), pack-reused 0
To https://github.com/devuser/my-project.git
[new branch] main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
[Push successful — the remote was already correct, error was a false alarm]Now a second example showing the error where the URL actually does need to be updated:
$ cd existing-project
$ git remote -v
origin https://github.com/devuser/old-project-name.git (fetch)
origin https://github.com/devuser/old-project-name.git (push)
[Origin exists but points to the old repository name]
$ git remote add origin https://github.com/devuser/new-project-name.git
error: remote origin already exists.
[Can't add — need to update instead]
$ git remote set-url origin https://github.com/devuser/new-project-name.git
[URL updated silently — no output means success]
$ git remote -v
origin https://github.com/devuser/new-project-name.git (fetch)
origin https://github.com/devuser/new-project-name.git (push)
[Confirmed — origin now points to the new URL]
$ git push -u origin main
Enumerating objects: 47, done.
Counting objects: 100% (47/47), done.
Delta compression using up to 8 threads
Compressing objects: 100% (31/31), done.
Writing objects: 100% (47/47), 18.42 KiB | 3.07 MiB/s, done.
Total 47 (delta 8), reused 0 (delta 0), pack-reused 0
To https://github.com/devuser/new-project-name.git
[new branch] main -> main
Branch 'main' set up to track remote branch 'main' from 'origin'.
[Push successful]Prevention Tips — How to Avoid This Error Going Forward
The remote origin already exists error is genuinely harmless, but it does interrupt your flow. These habits will keep it from happening.
Tip 1 — Always Check Remotes Before Adding One
Make git remote -v a reflex before running git remote add. It takes two seconds and tells you immediately whether a remote already exists and where it’s pointing. If origin is already set up correctly, you can skip straight to git push. If it’s wrong, you know to use set-url instead of add.
Tip 2 — Understand GitHub’s Repository Setup Instructions
GitHub’s “push an existing repository from the command line” instructions include git remote add origin URL. This is designed for a freshly initialized repository with no remotes. If you’ve already run git clone (which sets up origin automatically) or if you’ve already added a remote manually, these instructions will cause the “already exists” error. You don’t need to re-run them. Just skip the git remote add line and go straight to git push.
Tip 3 — Use git clone Instead of git init + git remote add
If you’re working with an existing GitHub repository, cloning it (git clone URL) sets up origin automatically and gives you a clean working state. Using git init for a project that already exists on GitHub and then manually adding the remote is more error-prone. Reserve git init for genuinely new projects that don’t exist on GitHub yet.
Tip 4 — Keep a Note of Your Remote Setup When Configuring Complex Multi-Remote Workflows
If you’re working with forks (origin + upstream), multi-platform mirrors (GitHub + GitLab), or deployment remotes, write down the intended configuration in a README, a CONTRIBUTING file, or a personal note. It makes re-running the setup on a new machine straightforward and prevents duplicate add attempts when you can’t remember what you’ve already configured.
Tip 5 — Know the Three Remote Commands by Heart
Three commands cover nearly every remote management scenario:
git remote -v — View all remotes and their URLs. Run this first, always.
git remote set-url origin URL — Update the URL of an existing remote.
git remote remove origin — Remove a remote entirely.
With these three in your toolkit, the “remote origin already exists” error is never more than one or two commands away from being resolved.
Tip 6 — Use Descriptive Remote Names for Non-Standard Setups
Origin is well understood as the primary remote. When you add additional remotes, use descriptive names that make their purpose obvious: upstream for the original repository of a fork, staging for a staging server, production for a production deployment target, gitlab for a GitLab mirror. Descriptive names prevent confusion when you’re running git push and need to specify the remote.
Tip 7 — Audit Remotes When Repurposing a Project Directory
If you’re reusing a project directory for a new project — copying files from an old project into a new one, repurposing a directory, or restoring from a backup — always run git remote -v early. You might be inheriting remote configuration from the previous use of that directory, which will cause unexpected behavior (pushing to the wrong repository) or this error when you try to set up fresh remotes.
FAQ
Q: Is it safe to remove the origin remote?
Yes, completely. The origin remote is just a pointer stored in your .git/config file. Removing it with git remote remove origin deletes that pointer but leaves every other part of your repository completely intact — your commits, your branches, your working files, your history, everything. You can re-add it any time with git remote add origin URL. The remote repository on GitHub is not affected in any way.
Q: Why does git clone automatically set up an origin remote?
When you clone a repository, Git needs to remember where you cloned from so that git push and git pull know where to communicate with. Git automatically creates a remote named origin pointing at the URL you cloned from, and sets your default branch to track origin/main (or origin/master). This is why running git remote add origin URL after cloning will always give you the “already exists” error — the remote was set up as part of the clone.
Q: What’s the difference between git remote set-url and git remote remove + git remote add?
Both achieve the same end result — changing the URL that origin points to. The difference is in how they get there. git remote set-url modifies the url field of the existing remote in-place, preserving any other configuration in that remote’s block (like custom fetch refspecs or push URLs). git remote remove followed by git remote add deletes the entire block and creates a new one from scratch. For most straightforward cases (just updating the URL), set-url is cleaner. For a completely fresh start, remove + add is appropriate.
Q: Can I rename the origin remote to something else?
Yes. The git remote rename command changes the name of an existing remote:
git remote rename origin github
After this, git remote -v will show:
github https://github.com/USERNAME/REPO.git (fetch)
github https://github.com/USERNAME/REPO.git (push)Note that renaming origin means you’ll need to specify the new name in subsequent push and pull commands (git push github main instead of git push origin main), or update your branch tracking configuration. For most workflows, keeping the name “origin” is the clearest choice since it’s universally understood.
Q: I ran git init inside a cloned repository by mistake. Now things look strange. How do I fix it?
Running git init inside an existing Git repository generally doesn’t do much damage — Git recognizes that .git already exists and typically just reinitiates a few things without deleting data. But if it caused issues, check git remote -v to see what remotes are configured, and git log –oneline to check that your commit history is intact. If the remote configuration looks wrong, use git remote set-url or git remote remove + git remote add to fix it. Your commit history should be unaffected.
Q: I’m getting “remote origin already exists” inside a GitHub Actions workflow. How do I handle it?
In CI/CD workflows that use git remote add, the error can appear if the runner already has origin configured (common when using actions/checkout which sets up the remote automatically). The cleanest fix is to use git remote set-url instead of git remote add, which works whether or not origin already exists. You can also use a conditional approach:
git remote | grep -q origin && git remote set-url origin NEW-URL || git remote add origin NEW-URLThis checks whether origin exists and uses set-url if it does, add if it doesn’t. Alternatively, structure your workflow to use the URL directly in push commands rather than modifying the remote configuration.
Q: How do I see the full remote configuration including fetch and push URLs?
The git remote -v command shows the basic fetch and push URLs. For the full configuration including any additional push URLs or custom fetch refspecs, look directly at the config file:
cat .git/config
Or use git remote show for a detailed view of a specific remote:
git remote show origin
This shows the remote URL, tracked branches, local branches configured for git pull, and local refs configured for git push. It’s a useful diagnostic tool for complex remote setups.
Q: Can I have multiple push URLs for the same remote?
Yes. This is a useful setup for pushing to GitHub and GitLab simultaneously. Use git remote set-url –add –push to add additional push URLs to an existing remote:
git remote set-url --add --push origin https://github.com/USERNAME/REPO.git
git remote set-url --add --push origin https://gitlab.com/USERNAME/REPO.gitAfter this, git push origin pushes to both URLs. Note that when you add push URLs this way, you replace the default push URL, so you need to add both the original and the new one. Verify with git remote -v to see both push URLs listed.
Q: What happens to my local commits if I change the remote URL?
Nothing. Your local commits, branches, history, and working files are entirely independent of the remote URL stored in .git/config. The remote URL is just a pointer that tells Git where to push and pull. Changing it, removing it, or replacing it has zero effect on your local history. Your commits are safe regardless of what you do to the remote configuration.
Q: I have a repository with no remote. How do I add one from scratch without hitting this error?
If git remote -v shows no remotes, you’re clear to add one directly:
git remote add origin https://github.com/USERNAME/REPO.git
Or with SSH:
git remote add origin git@github.com:USERNAME/REPO.git
The “already exists” error only appears when origin is already configured. On a fresh repository with no remotes, git remote add will work without any issues.
Related Errors
These errors frequently appear in the same workflow as “remote origin already exists” and are worth knowing about.
fatal: ‘origin’ does not appear to be a git repository
The opposite of “already exists” — you’re trying to use a remote named origin (in a git push, git pull, or git fetch) but no remote with that name is configured. Add it:
git remote add origin https://github.com/USERNAME/REPO.git
error: src refspec main does not match any
Appears when you try to push a branch that doesn’t exist locally yet. Usually happens on a fresh git init when no commits have been made. The main branch doesn’t exist until you make at least one commit:
git add .
git commit -m “Initial commit”
git push -u origin main
fatal: The current branch main has no upstream branch
Your local branch isn’t tracking any remote branch, so Git doesn’t know where to push. Fix it with:
git push –set-upstream origin main
Or shorthand:
git push -u origin main
After this, future git push commands on the main branch will automatically go to origin/main without needing to specify the remote and branch.
remote: Repository not found.
You have origin configured but the URL it points to doesn’t resolve to a repository you can access. Either the URL is wrong, you don’t have access to the repository, or the repository was deleted. Check the URL with git remote -v and verify your authentication.
fatal: remote origin already exists — but git remote -v shows nothing
This is a rare edge case where the .git/config file has a malformed or corrupted remote entry that doesn’t show up in git remote -v output but does prevent git remote add from working. Open the config file directly (cat .git/config) and look for any partial or malformed [remote “origin”] block. Delete it manually and retry git remote add origin URL.
error: failed to push some refs to ‘origin’
Not a remote configuration error, but one of the most common errors to appear right after successfully setting up origin. Usually means the remote has commits that your local doesn’t — typically because GitHub created a README or LICENSE file when you created the repository. Fix it with:
git pull origin main –rebase
git push origin main
Or if you want to overwrite the remote branch entirely (only safe if you’re sure you don’t need anything on the remote):
git push origin main –force
fatal: not a git repository (or any of the parent directories): .git
You ran a Git command outside of a Git repository. Navigate into your project directory first:
cd your-project-directory
Then retry the command.
Conclusion
The “remote origin already exists” error is one of the most benign errors Git can throw. It carries no risk to your code, no corruption of your repository, and no data loss of any kind. It’s a simple configuration conflict — Git already has a remote named “origin” and you tried to add another one.
The entire resolution comes down to one diagnostic step and one of four possible actions.
The diagnostic step is always git remote -v. Run it first, every time. It tells you whether origin already points to the right URL (in which case you just move on), or whether it points to the wrong URL (in which case you need to update it).
If origin is already correct — just push. git push -u origin main. The error was a non-issue and your setup is fine.
If origin needs to be updated — use git remote set-url origin NEW-URL. It’s one command, it works instantly, and it leaves everything else intact.
If you want a completely fresh start — use git remote remove origin followed by git remote add origin NEW-URL. Clean slate, no residue.
If you need a second remote — use git remote add DIFFERENT-NAME URL. Don’t touch origin at all.
If you need direct config control — edit .git/config in a text editor. Full transparency, full control.
That’s the complete picture. The error sounds more serious than it is — a reflex check of git remote -v and a single follow-up command is all it ever takes.
If you’re hitting this error repeatedly in a specific workflow — like a CI/CD pipeline or a team onboarding script — the long-term fix is to replace git remote add origin URL in your scripts with git remote set-url origin URL. Unlike add, set-url works whether or not the remote already exists, which means it’s idempotent — safe to run multiple times without error.
Related Resources
Git Official Documentation — git-remote
Git Official Documentation — git-config
Git Blogs – A collection of git troubleshooting and interview questions blogs and much more written by me.
About the Author
Kedar Salunkhe
DevOps Engineer | Seven years of fixing things that break at 2am
Kubernetes • OpenShift • AWS • Coffee
I’ve spent almost 7 years keeping production systems running, often when everyone else is asleep. These days I’m working with Kubernetes and OpenShift deployments, automating everything that can be automated, and occasionally remembering to document the things I fix. When I’m not troubleshooting clusters, I’m probably trying out new DevOps tools or explaining to someone why we can’t just “restart everything” as a debugging strategy. You can usually find me where the coffee is strong and the error logs are confusing.
If this guide saved you some time, share it with a teammate — this is one of those errors that catches everyone eventually.