Whether you've cloned a repo and need to point it at a different GitHub project, or you just want to clean up stray remote branches, Git gives you a few reliable commands to handle it. This post walks through the concepts and ends with a quick-reference cheat sheet you can bookmark.
Why You'd Change a Remote
The most common scenario is forking or migrating: you clone an existing repository, but your actual destination is a different GitHub repo—maybe your own fork, a renamed project, or a new organization. Rather than re-cloning from scratch, Git lets you simply repoint your local copy's origin remote, preserving all your commit history and local branches. stackoverflow
Checking Your Current Remote
Before changing anything, confirm what's currently set up:
git remote -v
This lists the remote name (usually origin) alongside its fetch and push URLs. It's good practice to run this both before and after any change to confirm the update took effect. docs.gitlab
Updating the Remote URL (Recommended Method)
The cleanest way to switch to a new GitHub repo is git remote set-url, which updates the existing origin in place without disturbing branch tracking or history: gist.github
git remote set-url origin <new-repo-url>
For example, switching to an HTTPS-based GitHub URL looks like git remote set-url origin https://github.com/OWNER/REPOSITORY.git, or for SSH, git@github.com:OWNER/REPOSITORY.git. Afterward, run git remote show origin to confirm the update and verify your local branches are correctly tracked to the new remote. docs.github
Removing and Re-adding the Remote (Alternative Method)
If you'd rather start clean, you can delete the remote entirely and add a new one under the same name:
git remote remove origin
git remote add origin <new-repo-url>
This achieves functionally the same result as set-url—it's mostly a matter of preference or troubleshooting stale configuration. Some teams prefer this approach when they want an explicit reset rather than an in-place edit. graphite
Handling Multiple Remotes
If you're managing more than one remote (e.g., origin and upstream for a fork), the same set-url pattern applies—just swap in the remote's name:
git remote set-url <remote_name> <new_url>
This is useful when you fork a repo, clone your fork, and also want an upstream remote pointing back to the original project you forked from. gitlab
Pushing After the Switch
Once your remote points to the new repo, push your code over:
git push -u origin main
If the new repo is empty, this works immediately. If it already has unrelated commit history, you may need git push origin --all or resolve merge conflicts with --allow-unrelated-histories first.
Deleting a Remote Branch
Separately, if you just want to remove a specific branch on the remote (not the whole remote itself), use:
git push origin --delete <branch-name>
Follow up with git fetch --prune to clean up any stale local references to the deleted branch.
Git Remote Cheatsheet
| Task | Command |
|---|---|
| View current remotes | git remote -v |
| Update remote URL (in place) | git remote set-url origin <new-url> |
| Remove a remote | git remote remove origin |
| Add a new remote | git remote add origin <new-url> |
| Rename a remote | git remote rename <old-name> <new-name> |
| Verify remote + tracking | git remote show origin |
| Update URL for any named remote | git remote set-url <remote_name> <new_url> |
| Push local branch to new remote | git push -u origin main |
| Delete a remote branch | git push origin --delete <branch-name> |
| Prune stale remote-tracking refs | git fetch --prune |
| List all remote branches | git branch -r |
Keep this table handy—git remote set-url covers 90% of "I need to point my repo somewhere else" situations, while remove + add is your fallback for a full reset.
Top comments (0)