Git Set URL Remote: Changing Where Your Repository Pushes

git remote set-url origin is the whole answer. What follows is why the change appeared not to work, and the cases where one URL is not enough.

Repositories move. An organisation renames itself, a project migrates between hosts, a team switches from HTTPS to SSH because token prompts got tiresome. In every case the local clone keeps pointing at the old address until you tell it otherwise.

The command is one line. The confusion is almost always credentials or a second remote nobody remembered.

Table of contents

• Look before you change
• Changing the URL
• HTTPS or SSH, and the credential question
• Separate push and fetch URLs
• When the change appears not to have worked
• Where the remote points in a deploy pipeline
• How this fits the rest of the stack
• FAQ

Look before you change

Start by seeing what is actually configured:

git remote -v

origin  https://github.com/acme/old-name.git (fetch)
origin  https://github.com/acme/old-name.git (push)

Two lines per remote, because fetch and push are configured separately even though they usually match. A repository can have several remotes — origin plus an upstream for a fork, or a deployment remote — and changing origin leaves the others pointing wherever they pointed.

For one remote’s URL specifically:

git remote get-url origin
git remote get-url --push origin   # the push URL, if it differs

Changing the URL

The command:

git remote set-url origin https://github.com/acme/new-name.git

Or to SSH:

git remote set-url origin [email protected]:acme/new-name.git

Nothing is transferred and nothing is validated — Git writes the value into .git/config and returns immediately. A typo is not caught here; it surfaces on the next fetch. Verify with git remote -v, then confirm with a real operation:

git fetch origin

Note the two URL formats. https://host/owner/repo.git uses a slash before the path. git@host:owner/repo.git uses a colon — it is SCP-style syntax, not a URL, and writing a slash there is a common and confusing mistake.

HTTPS or SSH, and the credential question

The practical difference is authentication.

HTTPS authenticates with a username and a personal access token. It works through corporate proxies and restrictive firewalls, which is often decisive. The cost is token management: tokens expire, and without a credential helper you are prompted constantly.

git config --global credential.helper manager  # Windows
git config --global credential.helper osxkeychain # macOS

SSH authenticates with a key pair. Once the key is on the host and loaded in your agent, pushes are silent forever. Port 22 is blocked on some networks, which is the usual reason people fall back to HTTPS.

Either is fine. What is not fine is having half your repositories on each with no idea which, so that authentication failures are always a small mystery. Pick one per machine and convert the strays.

Separate push and fetch URLs

set-url has a --push flag that sets the push URL independently:

# Fetch over HTTPS (works anywhere), push over SSH (no token prompts)
git remote set-url origin https://github.com/acme/repo.git
git remote set-url --push origin [email protected]:acme/repo.git

This is genuinely useful for read-mostly setups: CI clones over HTTPS with a read-only token while developers push over SSH.

You can also push to several places at once by adding push URLs:

git remote set-url --add --push origin [email protected]:acme/repo.git
git remote set-url --add --push origin [email protected]:acme/repo.git

One git push now writes to both, which is how mirrors are usually maintained. Be aware of the sharp edge: once you add a single push URL, the fetch URL is no longer used as an implicit push target, so the first --add --push must include the original destination or you will silently stop pushing there.

When the change appears not to have worked

Four causes, in the order they actually occur:

1. Cached credentials. The URL changed, but the credential helper still offers the old host’s token. Clear the stored entry — Credential Manager on Windows, Keychain Access on macOS — and let it prompt again.
2. A submodule. Submodules have their own remotes. Update .gitmodules, then run git submodule sync --recursive.
3. A different remote. You changed origin, but the branch tracks upstream. Check git branch -vv to see what each branch is following.
4. A URL rewrite rule. git config --get-regexp 'url\..*\.insteadof' reveals a global rule silently rewriting your new URL back to something else. Rare, and baffling when it happens.

The fastest diagnostic is GIT_CURL_VERBOSE=1 git fetch origin for HTTPS or ssh -T [email protected] for SSH. Both tell you which host you actually reached and as whom.

Where the remote points in a deploy pipeline

One case worth flagging: if a deployment is wired to a repository and the repository moves, the deployment does not follow. The build keeps working until the next push, then stops pulling anything — or worse, keeps building the old repository nobody is committing to any more.

After moving a repository, check every consumer: CI configuration, deployment integrations, webhooks, and any documentation with a clone URL in it. Host-side redirects from a rename help with git fetch but are not guaranteed to be honoured by every integration.

On RunxBuild, services and static sites build from a connected GitHub repository, so a repository move means reconnecting the project to the new location. The build log makes it obvious when a deploy is coming from somewhere unexpected.

How this fits the rest of the stack

git remote set-url origin <url> is a local config edit — instant, unvalidated, and easy to verify with git remote -v followed by a real fetch. When it seems not to work, suspect cached credentials, a submodule, or a remote you forgot existed. If the repository moved, remember that every deployment and CI integration pointing at it needs the same update, and the RunxBuild hosting calculator is the place to check what the services building from it cost while you are in there.

Useful related references:

• How to Create a Node Backend: From node app.js to a Live URL Without the Tutorial Cuts
• Dynamic URL: Why It Is Usually a Marketing-Team Phrase, and the Three Engineering Questions It Actually Contains
• See All Branches in Git: Local, Remote, and the Ones You Forgot
• Services on RunxBuild

FAQ

How do I change the remote URL of a Git repository?

Run git remote set-url origin <new-url>, then confirm with git remote -v. The change is a local edit to .git/config and is not validated, so follow it with git fetch origin to confirm the new address actually works.

How do I switch from HTTPS to SSH in Git?

Run git remote set-url origin git@host:owner/repo.git. Note the colon before the path — that is SCP-style syntax, not a URL, and using a slash there is a common mistake. Make sure your SSH key is added to the host first.

Why does Git still ask for the old credentials after changing the URL?

The credential helper caches per host and may still be offering the old entry. Clear the stored credential in Windows Credential Manager or macOS Keychain Access and let Git prompt again on the next operation.

Can a remote have different fetch and push URLs?

Yes. git remote set-url --push origin <url> sets the push URL independently, which is useful for fetching over HTTPS while pushing over SSH. --add --push lets you push to multiple destinations, though the first one you add replaces the implicit default.

Do I need to change the remote URL after renaming a repository?

Most hosts redirect the old URL, so fetches keep working, but you should update it anyway. Redirects are not guaranteed to be honoured by CI systems, deployment integrations or webhooks, and a stale URL is a confusing thing to leave behind.