Git小技巧：一个本地仓库同时推送到多个远程仓库

去年我把维护了大半年的一个开源小工具放在GitHub上，后来公司内部也想把代码镜像到自建的GitLab里作为备份。一开始我的做法很笨：先推GitHub，再切到GitLab的地址推一次，忘了切换就推错地方。后来花了一晚上研究Git的remote工作机制，才算彻底搞清楚“一个本地仓库同时推送到两个远程仓库”的几种做法。这篇文章就是把这些方案和背后的原理一起整理出来，包括完整的操作命令、配置文件解读、以及我踩过的认证和分支覆盖的坑。

如果你是刚用Git没多久的新手，看到“一个本地仓库推多个远程”可能会觉得有点绕。它的实际价值在于：不需要复制仓库目录，不需要来回改remote地址，只要配置一次，之后每次git push就能把提交分发到多个平台。比如我个人常用的场景就是GitHub做开源主页、Gitee做国内加速镜像、公司GitLab做内部存档，三个地址在一次push里全部搞定。

1. 什么场景下才需要“一推多仓”

先说需求。你未必真的需要这个功能，但如果你命中下面任意一种情况，就很值得把配置方法学会。

1.1 我的真实需求：开源项目多平台同步

我做开源项目的时候，GitHub是主阵地，但国内访问GitHub偶尔不稳定，有些用户习惯从Gitee拉代码。于是项目出现了两个远程仓库：GitHub负责国际社区，Gitee负责国内用户。

刚开始我手动推两边，后来推错了几次之后实在忍不了。比如有一次在Gitee上改了一行说明文档，顺手git push，结果代码被推到了上一次设置的remote里，GitHub上的在线文件没有同步，issue里就有用户问“你更新了但拉下来没变化”。这类问题表面上是“我忘了切地址”，本质上是没有把多远程的推送机制理顺。

如果你也在用“同一个项目分别维护两个平台”，建议直接配好一推多仓，而不是靠脑子记住切换。

1.2 远程仓库不只是“备份”，还承担着分发和协作职责

很多人以为“多推一份到另一个平台”就是多一个备份。其实远程仓库的意义远不止备份。

• GitHub：对外发布、接受issue、PR协作。
• Gitee / GitLab：国内下载加速、企业内网权限管理、CI/CD流水线触发。
• 自建GitLab：满足数据合规要求，代码不出内网也能被内部系统访问。

在这些场景里，两个远程仓库是同时工作的，不是“主仓库+备份仓库”的关系。你要保证两边的代码一致，还要保证每一次提交都被两边收到。

1.3 搞清楚你要的是“多地推送”还是“多地拉取”

这是最关键的一个区分。本文标题是“推送到两个远程仓库”，也就是push方向的多个目标。

但你一定要知道，Git的fetch和push是可以分开配置的。默认情况下，git remote add origin <url>会同时把fetch和push指到同一个地址。你可以改成：从A拉取，但推到A和B两个地址。更进阶一点，你甚至可以配置A分支只推A地址，B分支只推B地址。

所以在你动手之前先想清楚：你是需要“单次push分发到多个地址”，还是“从不同地址拉取不同分支”。前者是本文的重点，后者我会在第4节稍微提一下。

2. 先理解Git remote：一个名字背后可以挂多个URL

很多教程直接甩命令，却不解释为什么。结果用户一旦遇到“push成功但另一个仓库没更新”的情况就懵了。所以我先讲原理。

2.1 remote、fetch、push三个配置段的关系

你在终端里执行git remote add origin https://github.com/user/repo.git之后，.git/config文件里会多出这么一段：

[remote "origin"] url = https://github.com/user/repo.git fetch = +refs/heads/*:refs/remotes/origin/*

这段配置的含义是：你给https://github.com/user/repo.git起了一个别名origin，同时指定了fetch时要把远端所有分支映射到本地的refs/remotes/origin/命名空间下。

注意：这里只有一个url字段。git push origin时会往这个url推，git fetch origin时也会从这个url拉。

如果我们给同一个remote再加一个url，Git的行为就变了——它会把push请求发给所有url，但fetch仍然只从第一个url拉。

2.2 为什么Git天生支持多推送地址

Git的这个设计其实很务实。分布式版本控制系统的世界里，“某个仓库的官方地址”并不存在，每个人手里的仓库都可以互相推送。一个remote名下挂多个url，是为了支持“同一个逻辑远程，有多条物理通路”的场景。

最典型的例子是：你在公司内网，Git服务器在内网IP上；你在家办公，Git服务器映射到公网域名上。两个url指向同一台服务器，但网络路径不同。Git允许你把两个url都挂在同一个remote名下面，push的时候哪个通了用哪个，或者全部尝试。

这也就解释了为什么git remote set-url --add能把多个推送地址串在一起。

2.3 用命令查看仓库当前的remote配置

动手配置前，先学会看当前状态。我最常用的三条命令：

git remote -v

这条命令显示所有remote名及其对应的fetch/push地址。配置成功的话，你会看到同一个origin名下出现两条push记录。

git config --get-regexp "remote\..*\.(url|pushurl)"

这条命令能单独列出remote相关的url和pushurl配置，过滤掉干扰信息，排查问题时特别有用。

cat .git/config

直接看配置文件，理解最直观。Git的配置本质就是文本，命令行只是用来改文本的工具。

3. 方案一：单个remote挂载多个pushurl，一条git push完成双推

这是我最推荐的做法，也是目前团队里用得最多的。核心思路：只保留一个remote名（例如origin），但给这个remote配置两个pushurl。

3.1 操作步骤：git remote set-url --add

假设你现在的本地仓库已经关联了GitHub，地址是https://github.com/user/repo.git。

第一步，查看当前remote配置：

git remote -v

输出类似：

origin https://github.com/user/repo.git (fetch) origin https://github.com/user/repo.git (push)

第二步，添加第二个推送地址（比如Gitee）：

git remote set-url --add origin https://gitee.com/user/repo.git

第三步，再次查看：

git remote -v

输出变成：

origin https://github.com/user/repo.git (fetch) origin https://github.com/user/repo.git (push) origin https://gitee.com/user/repo.git (push)

注意fetch仍然只有一条，push变成了两条。此时直接执行：

git push origin master

Git会依次向两个地址推送，全部成功则命令退出码为0，任何一个失败会报错。

3.2 推送时发生了什么：Git会依次尝试所有pushurl

这里有一个容易误解的点。git push origin向多个地址推送时，不是并行推送，而是按顺序逐个尝试。

Git实际上做了这么几件事：

1. 读取remote.origin.pushurl，如果有多个url，按顺序排列。
2. 对每个url执行一次push协议操作。
3. 只要有一个url推送成功，Git继续尝试下一个。
4. 全部尝试完毕后，汇总结果。如果有地址失败，终端会打印"error: failed to push some refs"或者类似信息。

这意味着如果第一个地址推送失败（比如网络不通），第二个地址仍然会被尝试。所以不要担心“第一个挂了第二个也会被跳过”。

但也要注意：如果两个地址都有更新，而第二个地址因为某种原因失败，你只会看到部分成功。这时候最好检查一下两个平台上的提交记录，别以为git push报错就什么都没推上去。

3.3 这个方案的限制：可以双推，不能双拉

方案一最大的限制是：同一个remote的fetch只会从第一个url拉取。

如果你把GitHub放在第一个url，那么git fetch origin和git pull origin都只会从GitHub拉。Gitee上如果出现了GitHub上没有的提交（比如别人直接在Gitee上改了代码），它不会出现在你的本地仓库里。

解决方法是：

git fetch gitee

前提是你给Gitee也单独配置了一个remote名。或者你可以手动指定fetch地址：

git fetch https://gitee.com/user/repo.git master

第二种写法比较冷门，但确实有效。

提示：如果你需要“两个平台都能作为拉取源”，更合理的做法是方案二——把两个远程分别命名，fetch时各拉各的，push时通过别名一次推两。

4. 方案二：多个remote独立管理，用命令别名一键全推

方案一胜在配置简单、一条git push origin就够。但它把多个推送地址拧在了一个remote名下，灵活性差一些。方案二则是反着来：每个远程仓库都拥有独立的remote名，互不干扰，然后用Git别名把多条推送命令合并成一条。

4.1 添加多个remote并设置各自的推送分支

假设当前本地仓库还没有关联任何远程，或者你想重新配置：

git remote add github https://github.com/user/repo.git git remote add gitee https://gitee.com/user/repo.git

这时git remote -v会显示：

github https://github.com/user/repo.git (fetch) github https://github.com/user/repo.git (push) gitee https://gitee.com/user/repo.git (fetch) gitee https://gitee.com/user/repo.git (push)

执行git push github master，代码推到GitHub；执行git push gitee master，代码推到Gitee。两个remote互不依赖，你可以对不同remote配置不同的分支策略、不同的SSH密钥。

如果想给某个remote的push指定分支映射，可以这样：

git config remote.github.push refs/heads/master:refs/heads/master git config remote.gitee.push refs/heads/master:refs/heads/master

4.2 自定义git pushall别名实现一推多

每次敲两遍git push还是麻烦。Git别名可以帮你合并命令。

git config --global alias.pushall "!git push github master && git push gitee master"

配置完成后，执行：

git pushall

相当于依次执行了上面两条push命令。

我个人的习惯是再加一个fetchall：

git config --global alias.fetchall "!git fetch github && git fetch gitee"

这样拉取也可以一键到位。

用别名有个细节：Git别名如果以!开头，后面的内容会被当成shell命令执行。这意味着你可以写复杂的逻辑，比如：

git config --global alias.pushall "!for remote in github gitee; do git push $remote master; done"

但这种写法在Windows的cmd环境下可能不兼容，如果是Windows用户，更推荐用Shell脚本或者直接用方案一。

4.3 两个方案的核心区别与选型建议

我一直跟团队里的人说：方案一适合“多平台同步但以某一个平台为主”的场景，方案二适合“多个远程地位平等、各有各的管理策略”的场景。

我的建议是：如果你只是想把一个项目同时展示在GitHub和Gitee上，用方案一就够了，省事。如果你要维护一个项目，不同远程由不同人协作、需要分别拉取不同人的提交，用方案二更安全。

5. 从零到一的完整演示：同时推送GitHub与Gitee

这一节我把方案一和方案二的完整流程各走一遍，你跟着做就行。

5.1 创建远程仓库与本地仓库准备

先在GitHub和Gitee上分别创建同名仓库，比如都叫git-multi-push-demo。创建时不要把任何初始化文件（README、.gitignore、LICENSE）勾上，保持空仓库状态，否则待会儿本地推送会因为远程存在初始提交而冲突。

本地准备：

mkdir git-multi-push-demo cd git-multi-push-demo git init echo "# Git Multi Push Demo" > README.md git add README.md git commit -m "init"

5.2 方法一的完整操作流程

git remote add origin https://github.com/yourname/git-multi-push-demo.git git remote set-url --add origin https://gitee.com/yourname/git-multi-push-demo.git git push -u origin master

执行这条push命令的时候，GitHub和Gitee会分别要求你输入用户名密码（或者弹出凭据管理器）。全部成功后，你可以在git remote -v里看到两条push记录。

-u参数的作用是设置上游分支。由于一个remote的pushurl挂了两条，git push默认行为会被同时应用到两个地址，所以之后你只需要执行git push或者git push origin。

5.3 方法二的完整操作流程

git remote add github https://github.com/yourname/git-multi-push-demo.git git remote add gitee https://gitee.com/yourname/git-multi-push-demo.git git push -u github master git push -u gitee master

然后配置别名：

git config --global alias.pushall "!git push github master && git push gitee master"

之后每次提交后，执行git pushall即可。

5.4 验证远程仓库收到推送

推完之后不要急着关终端，验证一下：

git ls-remote https://github.com/yourname/git-multi-push-demo.git git ls-remote https://gitee.com/yourname/git-multi-push-demo.git

git ls-remote会列出远程仓库的所有分支和最新提交哈希。比较两条输出的第一行哈希值，如果一致，说明两边指向同一份提交。

我每次配置完新环境都会做一个额外检查：在本地git log里看当前HEAD的哈希，在GitHub和Gitee网页端分别看提交记录，确认三处版本号完全一致。虽然麻烦一点，但能彻底避免“我以为推上去了”的错觉。

6. 实战中躲不开的问题：认证、分支覆盖与误操作

一推多仓本身不难，难在配置完之后的日常使用。我把自己遇到的高频问题列在这里。

6.1 HTTPS认证：免密配置与凭据管理器

用HTTPS地址推送，每次都要输用户名密码，两个仓库输两遍，很烦。解决方式有三种。

第一种，使用Git自带的凭据管理器。Windows Git Bash安装时默认启用manager-core；macOS上使用osxkeychain。

git config --global credential.helper manager

存储一次之后，后续推送自动读取凭据。

第二种，把用户名密码写进URL（不推荐，密码可能被终端历史记录）：

git remote set-url origin https://username:token@github.com/yourname/repo.git

这种方式安全性较差，尤其是token泄露风险很高。

第三种，也是我强烈推荐的，改用SSH地址。

6.2 多平台SSH Key的复用与配置

GitHub和Gitee都支持SSH推送。地址格式分别是：

• GitHub:git@github.com:yourname/repo.git
• Gitee:git@gitee.com:yourname/repo.git

SSH免密的原理是：你的公钥分别添加到了两个平台，推送时Git走SSH协议，用本地的私钥完成认证。你完全可以只用一把密钥对，把同一个公钥添加到GitHub和Gitee上。也可以分开两把密钥，各自指定不同的remote。

我个人的做法是分开两把密钥，因为这样可以在一个平台上通过密钥名称快速识别是哪台电脑的操作。

如果使用多把密钥，在~/.ssh/config里加一段：

Host github.com HostName github.com User git IdentityFile ~/.ssh/id_ed25519_github Host gitee.com HostName gitee.com User git IdentityFile ~/.ssh/id_ed25519_gitee

这样git push github master会自动选用对应私钥。

6.3 一推多仓的合并冲突与分支保护

方案一里，两个远程仓库的master分支都被同一个本地仓库推送。如果在某个平台上直接通过网页改了文件（很多新手喜欢在Gitee网页端直接编辑），该平台的master分支就会领先于本地。

下次执行git push origin master时，Git会报non-fast-forward错误，refusing to update。

这时候千万不要执行git push -f强推。除非你确定要覆盖远程内容，否则强推会让对方平台的在线修改直接丢失。

正确做法：

git fetch origin git merge origin/master

但如果pushurl有两个，git fetch origin只从第一个url拉。你需要手动补拉另一个平台：

git fetch https://gitee.com/yourname/git-multi-push-demo.git master

如果本地没有你想要保留的Gitee修改，也可以用git cherry-pick把那条提交摘过来。

提示：在管理多个平台时，最好约定“所有修改都以本地仓库为权威”。任何平台的网页端直改，都要及时拉回本地，否则一定会遇到分支分叉。

6.4 限定只推某个远端

配置了一推多仓之后，有时候你反而只想推其中一个。比如Gitee正在做迁移，暂时不想把新提交推上去。

方案一的做法：临时删掉一个pushurl，推完再加回来。

git remote set-url --delete origin https://gitee.com/yourname/repo.git git push origin master git remote set-url --add origin https://gitee.com/yourname/repo.git

方案二就简单了，直接：

git push github master

因为两个remote本来就是分开的。这也是我建议“对刷新频率要求高、后续可能要单独操作”的项目采用方案二的原因。

7. 我的一推多仓实践心得

7.1 长期维护两个镜像仓库的体会

我用了大概一年多的方案一，最近半年换成了方案二。感受比较深的有几点。

第一，方案一日常维护极省心。git push origin一次双推，不需要记任何额外命令。但出了问题时，排查起来相对麻烦，因为两个地址都被塞在同一个remote下面，git remote -v信息拥挤，日志里也经常分不清哪条消息对应哪个平台。

第二，方案二看着命令多，但用别名包装之后维护体验很好。git pushall、git fetchall两个别名覆盖了95%的日常操作。当前端拉取、后端拉取分别需要从不同平台获取时，方案二明显更清晰。

第三，无论用哪种方案，一定要在团队内部定一个规矩：哪个平台作为“事实源”（source of truth），其余平台作为镜像。否则就会出现两个人分别往两个平台推了不同内容，最后互相覆盖的灾难。

我个人定的规则是：

• GitLab是主仓，CI从它触发。
• GitHub是镜像，对外开源展示。
• Gitee是加速镜像，只允许本地主仓单向推送，不允许网页端直改代码。

这套规则运行半年，没有出过代码一致性问题。

7.2 什么时候不建议使用一推多仓

并不是所有项目都适合这个功能，我遇到过两个反例。

第一个反例是私有大仓库。仓库体积超过1GB，历史提交极多，每次git push都要把所有对象压缩传输一遍，双推耗时加倍。这种情况下建议分开推，或者用git push --mirror单独做镜像同步。

第二个反例是不同平台需要不同分支策略的项目。比如公司内部GitLab上有dev、release分支，而GitHub上只放main分支。一推多仓会导致所有分支都被推上去，远端还需要手动清理。这类项目更适合用CI/CD流水线做条件触发同步。

7.3 最后的实用建议

如果你现在正在被“两个远程仓库来回切地址”折磨，直接照着第5节的流程配置一次，十分钟搞定，之后每天都能省一点精力。配置完记得把git remote -v的输出截图存一份，万一哪天配置文件被清了，还能快速恢复。

另外一个小技巧：.git/config文件里的remote.origin.pushurl支持多条配置，但如果你手动编辑配置文件，删除其中一条时一定要小心，不要误删了fetch行，否则git fetch会报fatal: No remote repository specified。

我见过不少同事在这上面卡壳，最后都是老老实实回到命令行用git remote set-url --delete操作，而不是直接改配置文件。关于这一点，我的建议也很简单：命令行能完成的配置操作，尽量别手改文件。Git的配置文件格式虽然简单，但出错时排查成本比敲几条命令高得多。