git修改域名的核心操作，不是重新clone仓库，而是用git remote set-url origin切换远程地址，一行命令保留全部提交历史。这篇文章就把远程仓库换地址这件事说透：从命令原理、三种实操方式，到换完域名后推送失败的排查思路，全部覆盖,看完直接上手改。
git修改远程仓库地址，先确认这三个信息
有个典型场景：公司的GitLab服务器要从git.dev.company.com整体迁到gitlab.internal.company.com，运维那边域名一换，本地几十个仓库全部找不到家了，这时候急着改origin地址，不如先确认三个信息,省得改完又来回折腾。
第一个信息是新域名的完整URL格式，GitLab、GitHub这类平台换域名后，仓库路径通常保留原样，只有主机部分变动，比如旧地址是http://git.dev.company.com/team/project.git，新地址大概率是http://gitlab.internal.company.com/team/project.git,组名和项目名不变。
第二个信息是仓库的访问协议，同一台服务器,HTTP和SSH的地址格式完全不同：
| 协议 | 地址格式 | 适用场景 |
|---|---|---|
| HTTP | http://域名/组/仓库.git |
内网快速配好，需要输入账号密码 |
| SSH | git@域名:组/仓库.git（GitHub用git@，GitLab同理） |
免密推送，公钥配置过一次长期有效 |
| HTTPS | https://域名/组/仓库.git |
国内代码托管平台默认推荐，凭证可缓存 |
第三个信息是当前本地是否有未推送的分支，执行git status看一遍，如果有未推送的提交，改完域名后推送时会遇到src refspec相关的提示，提前知道心里有底，这三个信息确认完,下一步动手改。
git修改域名，推荐git remote set-url origin命令
远程仓库地址这个东西，git专门提供了一个修改命令，不用删掉origin重新添加，一条命令替换新旧地址，是git修改远程仓库地址最直接的方式,格式如下：
git remote set-url origin http://gitlab.internal.company.com/team/project.git
执行完以后，用git remote -v验证输出：
origin http://gitlab.internal.company.com/team/project.git (fetch) origin http://gitlab.internal.company.com/team/project.git (push)
看到fetch和push两行都指向新地址，说明git修改域名这步已经成功，接下来正常git push即可，本地分支、提交历史、tag都不会受任何影响。
git remote set-url用法详解
这个命令的完整形态是git remote set-url <远程仓库名> <新地址>，其中origin是默认的远程仓库名，也可以用git remote查看本地配置的其他名字。
如果新地址的推送协议变了，比如原来用公网地址，现在改成内网SSH地址，同样用这条命令,地址写法换一下：
git remote set-url origin git@gitlab.internal.company.com:team/project.git
需要注意一点：修改地址后，本地缓存的凭证可能需要重新输入，HTTP协议下，第一次推送会弹出账号密码输入框，输一次之后git会默认记住，如果之前用git config credential.helper store配置过存储，新域名的凭证也会被记录下来，SSH协议则无需关心,公钥匹配的是服务器而不是域名本身。
git更换远程仓库域名，另两种方式和适用场景
git remote set-url是改地址的常规操作，但特殊场景下,另两种方式更合适。
第一种方式是删除再重新添加，适合地址变动特别大、或者想顺便改远程仓库名的场景（GitHub改完仓库名后远程地址必然变化）：
git remote rm origin git remote add origin git@github.com:username/new-repo-name.git
这个方式有个好处，可以在git remote add这一步顺手配置--fetch和--push两个不同地址，把一个仓库同时推到两个平台，比如一个项目要同时维护GitHub和Gitee,同步到第二个免费远程仓库：
git remote set-url origin --add git@gitee.com:username/project.git
这样每次git push会同时推送到两个平台，国内访问Gitee速度快，海外用户走GitHub,两边代码保持同步。
第二种方式是直接编辑.git/config
文件，适合对git内部结构比较熟、或者需要批量改大量仓库配置的情况，用文本编辑器打开仓库根目录下的.git/config：
[remote "origin"]
url = git@github.com:username/project.git
fetch = +refs/heads/:refs/remotes/origin/
把这个url的值直接改成新地址，保存退出即可，改完之后同理用git remote -v验证。
三种方式对比
| 修改方式 | 命令复杂度 | 适用场景 | 风险程度 |
|---|---|---|---|
git remote set-url |
一行命令 | 常规换域名，最推荐 | 低 |
rm + add |
两条命令 | 换平台或改远程仓库名 | 低 |
| 改config文件 | 直接编辑 | 批量修改、脚本操作用 | 中（手抖易错） |
git修改域名后推送失败，排查思路
域名改完，推送时各种问题就找上门了，最典型的是remote: Incorrect username or password ( access token )，这是HTTP协议的凭证问题，排查思路先分清是账号密码不对，还是权限不对，GitLab上简单看一下项目设置里的Members,确认当前账号有没有push权限。
如果是Permission denied (publickey)，问题出在SSH密钥上，域名换了，但SSH公钥是和账号绑定的，跟域名没有直接关系，所以这类错误多半是本地没加载正确的私钥，用ssh -T验证一下：
ssh -T git@gitee.com ssh -T git@github.com
能返回Hi, xxx! You've successfully authenticated说明SSH链路通畅，问题可能出在分支追踪状态上，部分仓库换域名后，本地分支和远程分支的追踪关系会变得混乱，推送时报fatal: The current branch master has no upstream branch,解决方案是用显式指定：
git push --set-upstream origin master
另一个容易被忽略的点是HTTP版的凭证缓存失效，如果之前用http.extraheader配置过token，换域名后token还是旧的，需要重新生成一个访问令牌，GitLab和Gitee都在个人设置里有Access Tokens
入口，生成后替换本地缓存，多数情况下，git修改域名后推送失败，罪魁祸首不是地址写错,而是凭证没同步更新。
批量仓库换域名，脚本化迁移思路
手头如果有几十个仓库分布在同一个父目录下，一个接一个执行git remote set-url过于低效，批量修改的思路是：先找出所有包含.git目录的项目文件夹,然后批量执行地址替换。
具体迁移思路如下：
- 写一个
for循环，遍历指定目录下的所有子目录，判断是否存在.git配置 - 用
sed直接替换.git/config里的域名，把git.dev.company.com统一替换成gitlab.internal.company.com - 替换前先备份，复制一份
config为config.bak，出问题能回滚 - 替换后循环执行
git remote -v验证
批量操作前建议先在一个仓库上测试，确认新旧地址的URL结构完全对齐，比如旧平台是GitLab，新平台换成Gitee，不仅域名变了，路径也可能从group/project.git变成owner/project.git，这种属于仓库改名而非单纯换域名，不能用简单的替换逻辑处理，批量迁移的高危点就在路径差异上,建议逐个确认而非无脑替换。
git修改域名常见问题
git修改域名后，历史提交记录会丢吗？ 不会。git remote set-url修改的只是远程仓库的URL地址，本地提交链不会被动过一根汗毛，所有提交记录、分支、tag、reflog都会原样保留,推送时会像什么都没发生一样正常同步。
git修改域名和修改远程仓库URL是一回事吗？ 是同一个意思，域名是URL的一部分，git操作层面只认URL，不关心域名变化，无论平台是GitHub改成了自建GitLab，还是服务器从旧IP迁到新IP,本质都是改一下远程地址指向。
改完域名后push一直要求输入账号密码，怎么处理？ HTTP协议下首次推送会提示输入凭证，git默认缓存15分钟，可配置长时间存储，如果每次推送都要求重输，执行git config credential.helper store启用永久存储，并完成一次身份验证，之后的推送不再弹窗，系统也会在密钥管理里保存这份凭证,换电脑或删除凭证后失效。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/657111.html
