直接结论：不要用 git clone --mirror 做跨国镜像，尤其当目标仓库有大量无关分支时——它会把所有分支、标签、甚至已删除的远程引用都拉下来，白白消耗带宽和存储，还拖慢同步速度。
直接结论：不要用 git clone --mirror 做跨国镜像，尤其当目标仓库有大量无关分支时——它会把所有分支、标签、甚至已删除的远程引用都拉下来，白白消耗带宽和存储，还拖慢同步速度。
为什么 git clone --mirror 在跨国场景下反而有害
这个命令本质是创建一个“全量裸仓库”，它会递归复制 refs/ 下所有内容：包括 refs/heads/*、refs/tags/*、refs/remotes/origin/*，甚至 refs/stash 和一些临时引用。海外主仓（比如 GitHub）常有几十个 CI 临时分支、废弃的 PR 分支、大量未清理的 tags，这些在镜像里全被保留，导致：
- 同步耗时翻倍：每次
git remote update --prune都要遍历并比对全部引用，网络延迟越高，超时风险越大 - 本地磁盘占用激增：一个 500MB 的主仓，镜像后可能膨胀到 2GB+，只因存了上百个没人用的
pr-1234分支 - CI 拉取变慢：下游构建脚本若用
git ls-remote列分支，会扫到一堆无效 ref，解析时间从毫秒级升至秒级
用 git clone --bare + git config remote.origin.fetch 精确控制同步范围
真正适合跨国镜像的做法，是先建裸仓，再手动定义哪些 ref 要拉，哪些跳过。核心是改写 remote.origin.fetch 配置项，而不是依赖默认的 +refs/*:refs/*。
例如，只同步 main、develop 和所有 v* 标签：
git clone --bare https://github.com/org/repo.git cd repo.git git config remote.origin.fetch "+refs/heads/main:refs/heads/main" git config --add remote.origin.fetch "+refs/heads/develop:refs/heads/develop" git config --add remote.origin.fetch "+refs/tags/v*:refs/tags/v*"
这样做的效果：
- 同步命令
git fetch origin只拉这三类 ref，不碰其他分支 -
--prune也只清理这三类对应的历史引用，不会误删你手动加的其他配置 - 后续可随时用
git config --add追加新分支，比如上线前加release/2.1
git push --force-with-lease 比 --mirror 更安全地更新镜像
很多人误以为 --mirror 是唯一能“保持镜像一致”的方式，其实不然。它等价于 --force --all --tags，会无差别覆盖目标端所有 ref —— 如果镜像服务器上有人手动推送过测试分支，--mirror 会把它干掉。
更稳妥的做法是用 git push --force-with-lease 配合明确的 refspec：
git push mirror-server \ +refs/heads/main:refs/heads/main \ +refs/heads/develop:refs/heads/develop \ +refs/tags/v*:refs/tags/v*
好处是：
- 只更新你指定的 ref，不碰其他分支（比如运维人员在镜像上建的
hotfix/tmp不会被清掉） -
--force-with-lease会检查目标 ref 是否被他人更新过，避免覆盖他人工作 - 失败时有明确提示，比如
! [rejected] main -> main (stale info)，便于排查谁动了镜像
同步脚本里必须加 git fsck 和超时控制
跨国链路不稳定，git fetch 或 git push 卡住是常态。光靠重试不够，得主动防御：
- 每次同步前跑
git fsck --no-reflogs，验证对象数据库完整性，避免因断连导致的半截 pack 文件污染仓库 - 用
timeout 300 git fetch origin限制单次 fetch 不超过 5 分钟，超时就中止，防止挂起整个 cron 任务 - 同步后检查
git for-each-ref --format="%(refname)" refs/heads/输出是否包含预期分支名，别只看命令返回码
真正容易被忽略的点不是“怎么配”，而是“怎么防错”——镜像仓库一旦出错，下游所有开发者都会感知到延迟或失败，但错误日志往往只留在服务器后台。建议把 git fsck 结果和 ref 列表 diff 写入日志，并设置告警阈值（比如连续 3 次缺失 main 分支就发钉钉）。
