git remote set-url 不生效的首要原因是 remote 名称错误，需用 git remote -v 确认实际名称；其次注意 https/ssh 协议与凭证匹配、子模块需单独更新、ci 脚本中地址可能硬编码。
git remote set-url 改不生效？先确认 remote 名字对不对
很多人执行 git remote set-url origin https://new.com/repo.git 后，git push 还是推到旧地址——根本原因是当前仓库压根没有叫 origin 的 remote。Git 不强制要求 remote 名为 origin，你可能用的是 upstream、github 或其他自定义名。
- 用
git remote -v查看当前所有 remote 及其 URL，别凭记忆猜名字 - 如果输出里没有
origin，就别硬改它；按实际名字操作，比如git remote set-url upstream https://... - 如果想统一用
origin，可以先删掉旧的：git remote remove upstream，再重命名：git remote add origin https://...
HTTPS 和 SSH 地址混用，导致认证失败或权限拒绝
改地址时最容易忽略协议差异：HTTPS 地址走账号密码 / token 认证，SSH 地址依赖本地 id_rsa 和公钥配置。强行把 HTTPS 换成 SSH（或反过来）却不配好对应凭证，git push 就会卡住或报错 Permission denied (publickey) 或 Authentication failed。
- 检查新地址协议是否匹配你的凭证方式：GitHub 推荐 HTTPS + personal access token，GitLab 企业版常强制 SSH
- HTTPS 地址中含用户名（如
https://user@github.com/...）会导致 Git 忽略 ~/.git-credentials，应去掉用户部分，靠凭据管理器处理 - SSH 地址必须以
git@host:开头，不是ssh://git@host/...（虽部分 Git 版本支持，但兼容性差）
子模块（submodule）里的远程地址不会自动同步
主仓库改了 remote，不影响已初始化的 submodule。每个 submodule 都有自己独立的 .git/config，里面的 url 字段仍指向旧地址。后续 git submodule update 会拉取失败。
- 进 submodule 目录，手动运行
git remote set-url origin https://new.com/sub-repo.git - 或者批量更新（在主仓库根目录执行）：
git submodule foreach 'git remote set-url origin $(git config --file .gitmodules submodule.$name.url)'，前提是.gitmodules已提前更新 - 改完记得
git add .gitmodules并提交，否则别人 clone 时 submodule URL 还是旧的
CI/CD 脚本里硬编码了远程地址，本地改了也没用
很多自动化流程（比如 GitHub Actions、Jenkinsfile）直接写死 git push https://old.com/repo.git 或用环境变量拼 URL。这时你在本地改 git remote 完全不影响 CI 行为。
- 搜索项目中所有
.yml、.sh、Jenkinsfile文件， grepgit push、git remote add、https://等关键词 - CI 中优先使用 Git 内置变量，比如
$GITHUB_SERVER_URL/$GITHUB_REPOSITORY.git，而不是手敲域名 - 如果必须写死，确保和
.gitmodules、CI 配置、部署文档三处保持一致，漏一处就出问题
remote 地址本身很简单，但真正难的是它散落在 Git 配置、子模块、CI 脚本、凭据管理器、甚至开发文档里。改一处，漏五处，是最常见的线上事故源头。
