A repository move does not require throwing away a useful clone. If the project moves organizations, changes hosts, or is renamed, your local branches, stash, reflog, hooks, and unpushed work can stay right where they are. Update the remote deliberately, verify it, and then decide whether the branch topology also needs work.
Start by recording what you have
Before changing anything, inspect the remote and the current branch:
git status --short --branch
git remote -v
git branch -vv
This catches two easy mistakes. First, a remote can have different fetch and
push URLs. Second, an old branch may be tracking a branch that was renamed from
master to main, or that no longer exists at the destination.
If you have uncommitted work, it is usually fine to update a remote, but this is a bad moment to combine a remote migration with a history rewrite. Make a checkpoint commit or stash only if that is already part of your normal workflow.
Change the URL without deleting the remote
For the ordinary case, use set-url:
git remote set-url origin git@github.com:new-owner/project.git
git remote get-url origin
This is safer and clearer than removing and recreating origin: it preserves
the remote's fetch refspec, any remote-specific configuration, and a separate
push URL if one exists. If the new host requires another SSH account, configure
that identity first; see using a per-repository SSH identity.
For a distinct write destination, set the push URL explicitly:
git remote set-url --push origin git@github.com:new-owner/project.git
git remote get-url --all origin
Verify the destination before changing branches
Ask the server for references:
git ls-remote --heads origin
git fetch --prune origin
The first command proves the URL and authorization are correct. The second updates remote-tracking branches and removes references that disappeared from the old server. It does not delete your local branches or working files.
Now compare the branch you are on with its intended upstream:
git branch -vv
git branch --set-upstream-to=origin/main main
git status --short --branch
Use the last command only after confirming the destination branch really is
main. A project may still use master, a release branch, or a protected
default branch with a different name.
Handle the less tidy migrations
When the destination was created from a different history, do not force-push because Git says the histories diverge. Compare first:
git log --oneline --left-right --graph HEAD...origin/main
That output tells you whether the remote contains work you need, your local branch contains unpublished work, or the repositories are genuinely unrelated. For an intentional integration, create a backup branch before rebasing or merging. Rebase versus merge explains why those operations have different collaboration consequences.
Submodules are another common surprise. After moving a parent repository, check
.gitmodules and each nested repository's own remote; changing the parent
remote does not rewrite submodule URLs.
Roll back cleanly
If the new URL is wrong, set it back:
git remote set-url origin git@github.com:old-owner/project.git
git fetch origin
Because the remote name stayed intact, rollback is one reversible command—not a new clone and not a recovery exercise. Treat a repository move as transport configuration first, then separately address authentication and branch policy.
