Repoint and Push a Remote

Inspect remotes

git remote -v                    # fetch + push URLs for all remotes
git remote get-url origin        # just origin's URL

Repoint an existing remote

git remote set-url origin <url>

Touches only .git/config — never modifies the working tree. If the output looks “wrong” afterward, that’s almost always unrelated pre-existing working-tree state, not this command: changing a remote URL updates a pointer and nothing else, it cannot delete files or switch branches.

Add a remote when none is set

git remote add origin <url>
git push -u origin --all     # push all branches, set upstream tracking
git push -u origin --tags    # push tags

Keep the old remote, add a second

git remote add newrepo <url>
git push -u newrepo --all

Replay local commits on top of upstream’s latest

git branch -a                    # list all local and remote branches
git log --oneline -5             # check whether a branch diverges
 
git remote add upstream <url>
git fetch upstream
git rebase upstream/main

After rebasing an already-pushed branch, the push needs a force:

git push --force-with-lease

Safe for solo repos; do not force-push a branch others have already pulled.

Export a patch instead of pushing a branch

Useful when you lack branch-create permission on the target repo:

git format-patch origin/main --stdout > my-change.patch

Recipient applies it with git am.

Standard branch-and-push

git checkout -b feature/my-change && git push -u origin feature/my-change

GitLab-specific

Branch creation and forking are role-gated (Developer minimum). Unlike GitHub, GitLab requires a formal fork-network relationship between projects to open a merge request — an unrelated new repo cannot MR into the original.

See also

• Rehoming a Fork — moving a fork to a new home remote.
• GitHub Auth for Local Git Operations — credentials for pushing from a local clone.