Change Git remote URL - repoint origin to NAS safely

Use git remote set-url to repoint your local origin from the USB copy to the NAS; this updates the URL stored in .git/config and does not touch commits, branches, or tags. Run git remote -v to confirm, then git fetch origin (or git pull) to sync — no re-clone or history loss required. If you prefer, adding a new remote name and then removing or renaming the old one also preserves history, but set-url is the simplest and safest.

Contents

• Change the git remote URL (git remote set-url)
• Add a new remote vs rename/remove the old one (git remote add origin)
• Step-by-step: safe workflow to switch origin to NAS
• Troubleshooting & divergent histories
• Sources
• Conclusion

Change the git remote URL (git remote set-url)

The cleanest way to point your local repo’s origin at the NAS is:

• Check the current remote(s):
  git remote -v shows fetch/push URLs and the remote names.
• Update the URL:
  git remote set-url origin <new-url> — for example a mounted path:
  git remote set-url origin /mnt/nas/project.git
  or an SSH URL:
  git remote set-url origin git@nas.example:/path/project.git.
• Verify and test:
  git remote -v then git fetch origin (or git pull origin <branch>).

This only edits the remote.origin.url value in your repository configuration; it does not rewrite commits or branches. The official git documentation explains that remotes are just configuration entries and can be changed safely using git remote set-url (Git - git-remote Documentation). GitHub’s guide shows the same workflow for HTTPS/SSH cases (Managing remote repositories - GitHub Docs).

A couple of useful variants:

• If your fetch and push URLs differ, update just the push URL:
  git remote set-url --push origin <push-url>
• To see the URL value directly:
  git config --get remote.origin.url

Why this is safe: you’re only changing where Git looks for/contacts the remote. Your local commits, refs, tags, and the object database remain untouched.

Add a new remote vs rename/remove the old one (git remote add origin)

You mentioned adding a new remote and deleting the old one. That’s fine — it won’t delete commits either — because remotes are merely named pointers to URLs. Here are common, safe patterns.

1. Keep both (rename old, add new) — handy as a backup:

git remote rename origin usb-origin
git remote add origin git@nas.example:/path/project.git
git remote -v

Now usb-origin points to the USB copy and origin points to the NAS. No history changed.

2. Add new remote and remove the old one:

git remote add nas git@nas.example:/path/project.git
git remote remove origin
git remote rename nas origin # optional: make the new remote the canonical "origin"

3. Direct replace (quick): git remote set-url origin <new-url> — simpler and the usual choice.

If you cloned from the NAS earlier and that clone worked, the NAS repo is already a valid remote target. If you plan to push to the NAS, confirm it’s configured to accept pushes (a bare repo is usual for shared remotes). The DevConnected tutorial covers practical examples of add/rename/remove workflows (How To Change Git Remote Origin - devconnected).

Short answer: either approach preserves local history. Use set-url when you just want to repoint origin; rename/add/remove when you want to keep the old remote available by a different name.

Step-by-step: safe workflow to switch origin to NAS

A conservative, practical checklist you can follow right now:

1. Inspect current remotes and URL:

• git remote -v
• git config --get remote.origin.url

2. (Optional) Fetch from the current origin to capture any remote-only commits:

• git fetch origin

3. Switch the URL (preferred, minimal):

• git remote set-url origin <nas-url>
• Example: git remote set-url origin /mnt/nas/project.git

4. Verify:

• git remote -v — confirm both fetch and push (or only fetch) point to NAS.
• git fetch origin — this hits the NAS now.

5. Compare branches if you suspect differences:

• git branch -r — list remote branches.
• git log --oneline origin/main..main (replace main with master or your branch) — shows commits in local branch not on origin.
• git log --oneline main..origin/main — shows commits on origin not in local.

6. Resolve divergence if needed:

• If NAS has new commits you don’t have: git merge origin/main or git pull --rebase origin main.
• If you want to push local commits up: git push origin main (may be rejected if remote has diverged).

7. If pushing and you get non-fast-forward rejections, don’t force blindly. Communicate and reconcile, or use git pull/git fetch + merge/rebase.

8. Optional tidy-up:

• Remove old remote if you renamed it earlier: git remote remove usb-origin.

GitLab’s tutorial walks through similar steps with screenshots and examples (Update Git remote URLs - GitLab Docs).

Troubleshooting & divergent histories

What if the NAS and your local work diverged? A few common cases and fixes.

• push rejected (non-fast-forward): the NAS has commits you don’t. Solution: git fetch origin then inspect and merge or rebase:
• git fetch origin
• git log --oneline --graph --decorate origin/main..main (or swap sides)
• git merge origin/main or git rebase origin/main depending on your workflow.
• You want to replace the NAS with your local repo (overwrite remote): that’s destructive. Use git push --force only if you’re certain no one else relies on the remote. Better: create a bare mirror on the NAS and push:
• On NAS: git init --bare /path/project.git
• Locally: git remote set-url origin /path/project.git then git push --mirror origin
• Remote permissions / protocol errors: if switching from a file path to SSH or HTTPS you may need SSH keys or credentials. After set-url, the first git fetch or git push will prompt for auth.
• Stale remote branches: run git remote prune origin to remove references to branches deleted on the NAS.

If you want a reference of how the community does the URL change, see the Stack Overflow Q&A with examples of git remote set-url and git remote add patterns (Stack Overflow discussion).

Sources

• Official Git documentation for remotes: https://git-scm.com/docs/git-remote
• GitHub guide on managing remotes: https://docs.github.com/en/get-started/git-basics/managing-remote-repositories
• GitLab tutorial on updating remote URLs: https://docs.gitlab.com/tutorials/update_git_remote_url/
• Stack Overflow Q&A (practical examples): https://stackoverflow.com/questions/2432764/how-do-i-change-the-uri-url-for-a-remote-git-repository
• Practical tutorial with alternatives: https://devconnected.com/how-to-change-git-remote-origin/

Conclusion

Use git remote set-url origin <new-url> to point your local origin at the NAS — quick, safe, and does not alter commit history. Verify with git remote -v and git fetch origin, then reconcile any divergent commits if necessary. If you prefer to keep the old USB remote around, rename it or add the NAS as a new remote; either way, git remote operations only change configuration, not your repository’s history.