Introduction

Changing a Git remote URL is a normal maintenance task when a repository moves, an organization is renamed, or a team switches from HTTPS to SSH. The key is to update the remote cleanly, then verify both fetch and push behavior so the repository does not quietly point at the wrong place.

Inspect the Current Remote First

Before changing anything, check what the repository is using now:

git remote -v
git branch -vv

git remote -v shows fetch and push URLs for each remote. git branch -vv shows what each local branch is tracking.

This matters because many repositories have more than one remote, usually something like origin and upstream. You need to update the correct one.

Change the URL with git remote set-url

The standard command is:

git remote set-url origin [email protected]:example-org/example-repo.git

For HTTPS, the command looks the same except for the URL:

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

Then verify the result:

git remote -v

This does not change your commit history, branches, or working tree. It only changes where that remote points.

Fetch and Push URLs Can Be Different

Git allows separate fetch and push targets. That is useful when a team fetches from a read-only mirror but pushes to the canonical repository.

Set them separately like this:

git remote set-url origin https://mirror.example.com/example-repo.git
git remote set-url --push origin [email protected]:example-org/example-repo.git

Check them with:

git remote get-url origin
git remote get-url --push origin

If you do not intentionally need separate endpoints, keep them the same to reduce confusion.

Test the New Configuration

Configuration output is not enough. Run a real network operation after the change:

git fetch --prune origin

If the remote is writable and you want to verify push access too, push a temporary branch:

git push origin HEAD:refs/heads/tmp-remote-check

If that succeeds, remove it:

git push origin --delete tmp-remote-check

That confirms the new remote works for both reading and writing.

Switching from HTTPS to SSH

Many teams eventually move from HTTPS to SSH because it avoids repeated username and token prompts once keys are configured correctly.

A typical SSH migration looks like this:

ssh -T [email protected]
git remote set-url origin [email protected]:example-org/example-repo.git
git fetch origin

The ssh -T step matters. If SSH authentication is not working, changing the Git URL alone will not fix push failures.

Multi-Remote Repositories

If you are working in a fork-based workflow, you may see something like:

git remote -v

Example output:

origin   [email protected]:your-user/project.git
upstream [email protected]:main-org/project.git

In that case, changing origin and changing upstream are very different operations. Be deliberate about which remote you are modifying.

Submodules and Automation

A remote URL change can also affect:

• CI jobs that run git fetch
• deployment scripts
• submodule URLs in .gitmodules

If submodules are involved, update and sync them too:

git submodule sync --recursive
git submodule update --init --recursive

Otherwise the top-level repository may be correct while nested repositories still point to the old host.

Common Pitfalls

The most common mistake is updating the wrong remote. Always inspect git remote -v before changing anything.

Another issue is assuming that a new URL also fixes authentication. HTTPS credentials, SSH keys, and host permissions are separate concerns.

People also forget that fetch and push URLs can differ. If pushes still go to the wrong place after a change, check the push URL specifically.

Finally, do not skip the real fetch and push test. A typo in the remote string may not be obvious until you actually hit the network.

Summary

• Use git remote set-url to change a remote without recloning the repository.
• Verify whether you are updating origin, upstream, or another remote.
• Check both fetch and push URLs after the change.
• Test the new configuration with a real fetch, and a temporary push if appropriate.
• If the repository uses SSH, confirm your SSH setup before blaming Git.