1. openclaw 双仓库同步的真实场景GitHub main 与 tags 镜像到 Gitee 到底难在哪openclaw 是一个在 GitHub 上活跃迭代的开源项目很多国内开发者会把它镜像一份到 Gitee用来加速 clone、方便团队内网拉取或者单纯作为备份。问题在于GitHub 那边的 main 分支和 tags 一直在往前走你第一次同步完之后过一段时间再想同步就会发现事情没那么简单——分支可能分叉、tags 可能漏推、远端 refs 对不上。我自己维护D:\source\openclawGitHub 本地克隆和D:\source\m-openclawGitee 本地克隆这两个目录有一段时间了。第一次同步的时候觉得挺顺git push origin --tags一敲就完事。但第二次同步时踩了几个坑Gitee 那边的 main 因为之前手动改过 README 产生了本地提交直接git pull会冲突tags 用普通 push 推不上去因为有些 tag 指向的 commit 在 Gitee 上根本不存在还有一次git ls-remote对比时发现两边 tag 数量差了 3 个排查半天才定位到是--tags和--follow-tags的行为差异。这篇内容就是把这套流程讲透。核心检索词是 openclaw 双仓库同步具体要解决的是 GitHub main 分支与全部 tags 如何完整镜像到 Gitee并且用git ls-remote验证两端 refs 一致性。适合谁看需要在国内环境维护镜像仓库的开发者尤其是已经同步过一次、现在要做增量同步的人。先说清楚一个前提GitHub 仓库和 Gitee 仓库是两个独立仓库不是 fork 关系Gitee 的 fork 机制和 GitHub 不互通。所以同步的本质是「从一个 remote 拉往另一个 remote 推」。理解这一点后面的命令就都好懂了。整个流程分四块配置 remote、拉取上游、推送镜像、验证一致性。下面按可复制的顺序展开每一步都给完整命令和预期输出。2. TaoToken 前置准备API Key、Base URL 与模型 ID 三件套怎么配在讲 git 命令之前先插一段环境准备。如果你在同步 openclaw 之后要跑它的 AI 相关功能或者用 Claude Code、Cline 这类工具做代码辅助需要先把模型接入配好。TaoToken 提供统一的 API 入口Base URL 是https://taotoken.net/api配合 API Key 和 Model ID 就能用。获取 Key 的路径打开 https://taotoken.net/api-keys 登录后在控制台创建 API Key。拿到之后不要硬编码在代码里建议放到环境变量。Windows PowerShell 下可以这样设$env:TAOTOKEN_API_KEY sk-你的key $env:TAOTOKEN_BASE_URL https://taotoken.net/api如果你用的是 Claude Code配置方式是在 settings 里指定 Base URL 和 Key。Claude Code 的配置文件通常在用户目录下的.claude/settings.json内容结构如下{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的key, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }注意这里三个字段缺一不可Base URL 指向 TaoToken 的 API 地址Key 用你在控制台创建的那串Model ID 要写完整模型名。很多人只配了前两个结果请求报 model not found就是漏了 Model ID。如果你用的是 Cline 或者 Roo Code 这类 VS Code 插件在插件设置里选 OpenAI Compatible然后填配置项值Base URLhttps://taotoken.net/apiAPI Keysk-你的keyModel IDclaude-sonnet-4-20250514Codex 的话配置写在~/.codex/auth.json里结构是{ OPENAI_API_KEY: sk-你的key, OPENAI_BASE_URL: https://taotoken.net/api }配好之后可以用一个最小请求验证连通性curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d {model:claude-sonnet-4-20250514,messages:[{role:user,content:ping}]}返回里有choices字段就说明通了。这一步和 git 同步本身没直接关系但如果你同步 openclaw 是为了跑它的 AI 功能先把接入配好能省后面很多事。更多接入细节可以看 https://taotoken.net/doc 。3. 可复制配置git remote 设置与 push --mirror 完整命令回到 git 同步。先确认两个目录的 remote 配置。进入 Gitee 本地目录D:\source\m-openclaw查看当前 remotecd D:\source\m-openclaw git remote -v预期输出类似origin gitgitee.com:yourname/m-openclaw.git (fetch) origin gitgitee.com:yourname/m-openclaw.git (push)如果之前已经加过 upstream 指向 GitHub这里还会多两行 upstream。没加过就执行git remote add upstream gitgithub.com:openclaw/openclaw.git如果报remote upstream already exists说明加过了跳过即可。想确认 upstream 指向对不对git remote get-url upstream接下来拉取上游的 main 和全部 tags。这里有个关键点git fetch upstream默认只拉分支不拉 tags。要拉 tags 必须显式加--tagsgit fetch upstream git fetch upstream --tags执行完你会看到类似输出列出新增的 tagFrom github.com:openclaw/openclaw * [new tag] v1.2.0 - v1.2.0 * [new tag] v1.2.1 - v1.2.1现在本地已经有了 GitHub 的最新 main 和全部 tags。接下来同步 main 分支。先切到 maingit checkout main然后有两种策略。如果 Gitee 仓库没有独立改动直接硬重置到上游最干净git reset --hard upstream/main如果 Gitee 仓库有独立提交比如你改过 README硬重置会丢掉这些改动。想保留的话用 mergegit merge upstream/mainmerge 可能产生冲突需要手动解决。实测下来镜像仓库最好保持「只读」状态不要在上面做独立改动否则每次同步都要处理冲突很烦。main 同步好之后推送到 Giteegit push origin main git push origin --tags如果 Gitee 的 main 和本地历史不一致比如之前硬重置过普通 push 会被拒绝需要加--forcegit push origin main --force注意--force会覆盖远端历史只在你确认 Gitee 仓库没有需要保留的独立提交时用。还有一种一步到位的做法用push --mirror。这个命令会把本地所有 refs分支、tags、甚至 remote-tracking refs原样推到目标仓库适合做纯镜像git push --mirror gitgitee.com:yourname/m-openclaw.git但--mirror有个副作用它会删除目标仓库上本地不存在的 refs。也就是说如果 Gitee 上有本地没有的分支会被删掉。所以用之前一定要确认本地是完整的镜像源。日常增量同步我更推荐分开推 main 和 tags可控性更强。如果你想把 GitHub 的 main 直接推成 Gitee 的 main也可以用 refspec 显式指定git push origin upstream/main:main --force git push origin --tags这样不用先 checkout 到 main适合脚本化。4. 验证请求与成功结果用 git ls-remote 对比两端 refs推完之后必须验证不然你永远不知道 tags 是不是真的全了。最直接的工具是git ls-remote它列出远端的所有 refs 和对应的 commit SHA。先看 GitHub 端的 main 和 tagsgit ls-remote upstream refs/heads/main git ls-remote --tags upstream再看 Gitee 端git ls-remote origin refs/heads/main git ls-remote --tags origin对比两边的 main SHA应该完全一致。比如 GitHub 返回a1b2c3d4e5f6... refs/heads/mainGitee 也应该是同一个 SHA。如果不一样说明推送没成功或者推的不是同一个 commit。tags 的对比稍微麻烦一点因为git ls-remote --tags会同时列出轻量 tag 和附注 tag 的解引用行带^{}后缀。附注 tag 会有两行一行是 tag 对象本身的 SHA一行是它指向的 commit SHA。对比时要注意这一点。更省事的做法是把两边输出排序后 diff。PowerShell 下可以这样git ls-remote --tags upstream | Sort-Object | Out-File gh-tags.txt git ls-remote --tags origin | Sort-Object | Out-File gitee-tags.txt Compare-Object (Get-Content gh-tags.txt) (Get-Content gitee-tags.txt)如果Compare-Object没有输出说明两边 tags 完全一致。有输出的话表示只在 Gitee 有表示只在 GitHub 有。实测下来最常见的差异是 GitHub 新增了 tag 但没同步过来重新执行git fetch upstream --tags和git push origin --tags即可。还有一个快速统计 tag 数量的办法(git ls-remote --tags upstream | Measure-Object).Count (git ls-remote --tags origin | Measure-Object).Count两个数字相等不代表内容一致可能有同名不同 SHA 的情况但数量不等一定有问题可以先用这个做粗筛。验证 main 分支的另一种方式是比对 commit SHAgit rev-parse upstream/main git rev-parse origin/main两个输出应该相同。如果不同检查是不是推送时用了错误的 refspec。成功的结果长这样main 的 SHA 两端一致tags 列表 diff 为空tag 数量相等。到这一步openclaw 的 GitHub main 与全部 tags 就完整镜像到 Gitee 了。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth 报错对照同步过程中和接入过程中会遇到一些典型报错这里集中列一下。git push 报! [rejected] main - main (non-fast-forward)这是最常见的一个。原因是 Gitee 的 main 有你本地没有的提交git 拒绝覆盖。解决方式二选一如果那些提交不要了用git push origin main --force如果要保留先git pull origin main合并再推。镜像仓库场景下通常直接 force。git fetch upstream --tags 报couldnt find remote ref检查 upstream 的 URL 是否正确以及 GitHub 仓库是否真的存在这个 tag。有时候 tag 被上游删了本地还留着git fetch --prune --tags可以清理。git ls-remote 返回空说明 remote 名字写错了或者没有网络权限。先git remote -v确认名字再git ls-remote upstream不带参数看能不能列出东西。接入侧报 401 UnauthorizedAPI Key 错了或者没带上。检查请求头是不是Authorization: Bearer sk-xxx注意 Bearer 后面有空格。Key 如果泄露了要去 https://taotoken.net/api-keys 重新生成。报 local proxy failed 或 connection refused本地网络配置问题。检查是不是设了HTTP_PROXY/HTTPS_PROXY环境变量指向了一个不可用的地址。清掉这些变量再试Remove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue返回体里 reading choices 报错或 choices 为空通常是 Model ID 写错了或者请求体格式不对。确认 model 字段是完整模型名messages 是数组且每项有 role 和 content。用最小请求体测试排除参数干扰。OAuth 相关报错Claude Code 或某些工具会走 OAuth 流程如果配置了 Base URL 又走了 OAuth可能冲突。检查 settings.json 里是不是同时存在 OAuth token 和 API Key 配置保留一种即可。push --mirror 之后 Gitee 上的分支消失了这是--mirror的正常行为它会删除目标端本地不存在的 refs。如果误删了从 GitHub 重新 fetch 再推一次。日常同步建议别用--mirror用分开推的方式。tags 推上去了但指向的 commit 在 Gitee 上不存在这种情况发生在 tag 指向的 commit 不在任何分支上时。git push origin --tags会尝试推送 tag 及其指向的对象一般能成功。如果失败先确保 main 已经推上去再推 tags。排查思路总结成一句先确认 remote 配置再确认 fetch 到了什么最后确认 push 推了什么每一步都用git ls-remote或git log看实际状态别靠猜。6. 语义一致 CTA同步完成后继续用 openclaw 做开发镜像同步只是第一步。openclaw 同步到 Gitee 之后国内团队拉取速度会快很多接下来就是拿它做实际开发。如果你在开发过程中需要 AI 辅助写代码、补测试、做 code review可以把模型接入配起来。需要 API Key 和接入文档的直接去 https://taotoken.net/api-keys 创建 Key配置细节看 https://taotoken.net/doc 。想先试试模型对话效果可以打开 https://taotoken.net/model-chat 直接聊几句确认模型可用再往工具里配。如果是长期做编码或者跑 Agent 任务Coding Plan 更划算入口在 https://taotoken.net/coding-plan 。Claude Code 用户可以直接参考 https://taotoken.net/claude-code 的接入说明把 Base URL、Key、Model ID 三件套填进去就能用。最后留一个实用习惯把同步命令写成一个 PowerShell 脚本每次要同步时跑一遍省得记命令。脚本大概长这样cd D:\source\m-openclaw git fetch upstream git fetch upstream --tags git checkout main git reset --hard upstream/main git push origin main --force git push origin --tags git ls-remote --tags upstream | Sort-Object | Out-File gh-tags.txt git ls-remote --tags origin | Sort-Object | Out-File gitee-tags.txt Compare-Object (Get-Content gh-tags.txt) (Get-Content gitee-tags.txt)跑完看 Compare-Object 有没有输出没有就说明这次同步干净利落。这个脚本我用了几个月比每次手动敲命令靠谱得多。