直接用 git remote set-url 修改远程地址，但必须验证 url、更新凭据、重设上游分支；先运行 git remote -v 确认是否需改，再按协议匹配格式执行命令，避免推送失败。
直接用 git remote set-url 就行，但改完不验证、不处理凭据、不重设上游分支，90% 的推送失败都出在这三步。
怎么确认当前远程地址真要改？
别急着敲命令。先运行 git remote -v，看输出里 fetch 和 push 的 URL 是否一致、是否指向你预期的新目标：
- 输出为空 → 本地根本没配远程，该用
git remote add origin <url></url>，不是改 - 看到两个不同 URL（比如
fetch是 HTTPS，push是 SSH）→ 这是人为分设过的，set-url默认会同时覆盖两者，属于正常行为 - URL 明显拼错（如
githib.com）或域名变更（如github.com→gitlab.internal）→ 必须改，且要顺带检查 SSHknown_hosts或 HTTPS 证书信任链 - 误把 fork 的上游（upstream）当成本地主远程（origin）→ 改错对象，
git remote不加-v只显示名字，容易漏掉其他远程
git remote set-url 命令的三个关键参数组合
这个命令默认只改共用 URL，但真实场景常需拆开控制：
- 标准写法：
git remote set-url origin https://new-host.com/u/repo.git→ 同时更新fetch和push地址 - 只改推送地址：
git remote set-url --push origin git@new-host:u/repo.git→ 适合 pull 走镜像站、push 走主站的 CI 场景 - 含特殊字符的 URL（如
@、空格、中文路径）必须用双引号包裹：git remote set-url origin "https://user:pass@host.com/我的项目.git"
改完地址后 push 还失败？先查这三件事
URL 对了，但 git push origin main 仍报错，问题大概率不在地址本身：
- SSH 协议：新主机公钥不在
~/.ssh/known_hosts里 → 报Permission denied (publickey)或host key verification failed；用ssh -T git@new-host先测通 - HTTPS 协议：旧凭据还缓存在系统里（尤其 Windows 的 Git Credential Manager）→ 报
403 Forbidden；运行git credential reject，然后输protocol=httpshost=new-domain.com再按两下回车清掉 - 分支上游没重设：之前执行过
git push --set-upstream origin main，改 URL 后git push仍会尝试推到旧地址；运行git branch --set-upstream-to=origin/main main强制刷新追踪关系
为什么别用 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会持续报错
协议切换（比如从 HTTPS 换 SSH）时，最容易被忽略的是认证依赖链——URL 只是门牌号，钥匙（凭据）、门锁规格（SSH host key）、甚至快递员联系方式（branch upstream）都得同步更新，缺一不可。
