先给个结论：改远程仓库地址，用 git remote set-url 这一行命令就够了。95% 的场景下，你根本不用去删远程、改配置文件，更不用写什么脚本。
怎么确认当前远程地址是否真的要改
但别急着敲命令，先跑一下 git remote -v，看看输出里两个 URL（fetch 和 push）是不是一致，是不是指向你预期的仓库。这一步容易踩几个坑：
- 很多人看到
origin就以为是唯一的远程——其实可能还有upstream或gitee，如果git remote不加-v，只显示名字，很容易漏掉其他远程。 - 容易把 fork 后的原始仓库当成本地的远程。比如你 fork 了 A 项目到自己的 B 仓库，但本地仍连着 A，这时候要改的其实是“上游”，而不是“你自己托管的那个地址”。
- CI/CD 环境里用的是 token 或 deploy key，URL 看起来一样，但认证方式已经变了——这种情况不是地址问题，是凭据问题。
git remote set-url 的三个关键用法
这个命令默认只改 fetch 和 push 共用的 URL；但有些场景必须拆开处理：
- 想让
git pull走 HTTPS（方便 CI），git push走 SSH（免输密码）？用git remote set-url --push origin git@github.com:user/repo.git单独设置 push 地址。 - 地址里要是带了特殊字符，比如
@、空格、中文路径，那就必须用双引号把整个 URL 包起来，比如git remote set-url origin "https://user:pass@host.com/repo.git"。 - 从 GitHub 切到 Gitee 或 GitLab 后，分支名可能不一致——Gitee 默认是
master，GitHub 新仓库是main。改完 URL 后，记得立刻执行git branch --set-upstream-to=origin/main main，否则git push会报“no upstream branch”。
为什么别急着用 git remote remove + add
表面上看是“重装”，其实会丢掉两样东西：
- 原有的远程
fetch配置，比如只拉refs/heads/*，不拉refs/pull/*。用remove再add会恢复成默认的全量 fetch，可能会拖慢git fetch。 - 所有已存在的远程跟踪分支（比如
origin/feature-x）不会自动重建，得等下次git fetch才生成。期间你想git checkout feature-x，要么失败，要么切到本地同名分支，很容易乱。 - 如果本地分支已经设置了
upstream，比如git branch --set-upstream-to=origin/dev dev，remove后这个关联还在，但指向了一个已经不存在的远程——这时候git status会直接报错。
改完之后最容易被忽略的一步
很多人改完 URL 就直接 git push，结果报 fatal: unable to access '...': Could not resolve host 或 Permission denied (publickey)。这不是地址没改对，而是协议依赖没跟上：
- 切到 HTTPS 地址后，没配凭据管理器：
git config --global credential.helper store（永久存）或cache（临时记 15 分钟）。 - 切到 SSH 地址后，没检查
ssh -T git@github.com是否通，或者新地址用了非标端口（比如ssh://git@example.com:2222/repo.git），但~/.ssh/config没配好 Host 别名。 - 本地 Git 版本低于 2.20，对某些新版 HTTPS URL（比如带 scope 的 token 地址）解析失败——这时候要么升级 Git，要么把 URL 格式降级。
