Git Worktree 不能替代 Submodule 解决跨仓库依赖版本锁定问题，它仅支持同一仓库内多分支并行开发，无法实现跨仓库的 commit ID 精确引用与自动化校验。
hotfix 分支怎么跨服务生效而不漏发
热修复必须以“发布事件”为单位统一推进，不能在 payment-service 和 id-generator 两个仓库各自建 hotfix/xxx 分支再单独发版——这极易导致只上线了前者，后者被遗忘，线上问题照旧。
正确做法是：在专用协调仓库（如 release-coordination）新建分支 hotfix/payment-id-failure-20260619，并在该分支中更新 release-manifest.json，明确指定两个服务要升级到的 commit ID 或 tag。
- CI/CD 流水线监听到新 tag（如
hotfix/v1.2.0-20260619）后，自动触发两服务构建；若支持增量部署，可只部署实际变更的服务，但必须校验release-manifest.json中所有依赖项是否已就位 - 禁止直接修改子模块路径下的
.git目录或手动git pull—— 这会绕过 manifest 约束，导致版本漂移 - 所有 hotfix 的 manifest 提交必须走 PR + 人工确认流程，避免脚本误写版本号
submodule 版本锁定与更新时的常见踩坑点
Submodule 不是“自动同步”的依赖，它只记录一个 commit ID（如 service-auth @ a1b2c3d），不会随上游 push 自动更新。很多人误以为拉取主项目就能同步子模块，结果跑起来还是旧代码。
更新 submodule 的正确姿势是：
- 先进入子模块目录：
cd services/auth，执行git pull origin main拉取最新提交 - 回到主项目根目录，用
git add services/auth把新 commit ID 提交进主项目 - 切忌直接在主项目里运行
git submodule update --remote—— 它会按 .gitmodules 里写的 branch 拉取，可能引入未经验证的变更 - 如果子模块用了
-b release/v1.2参数添加，那它的 HEAD 是 detached，不能直接git commit；必须先git checkout release/v1.2再改，否则下次git submodule update会丢弃你的修改
多仓库分支结构如何保持一致
微服务各仓库都叫 main 分支不等于它们就对齐了——每个仓库的 main 可能指向不同 commit，且没有强制约束机制。
GitHub 仓库备份技能 - 将 OpenClaw 工作空间自动或手动备份至 GitHub 私有仓库。支持自动定时备份和手动交互式配置，引导完成 Token 配置、仓库创建、首次备份及定时任务设置。用途：(1) 首次设置 (2) 日常备份。
真正有效的对齐靠的是外部清单（manifest）+ 自动化校验，而不是命名约定：
- 所有服务仓库的 CI 流水线必须读取
release-manifest.json中对应字段，校验当前构建的 commit 是否匹配清单要求；不匹配则立即失败 - 禁止在子模块中使用
git checkout -b创建本地分支并推送——这会让 submodule 的远程 tracking 分支和 manifest 脱节 - 如果某服务需临时基于旧版 manifest 发布，应在协调仓库新建分支（如
release/v1.2.3-hotpatch），而非在服务仓库自己切分支
git worktree 能否替代 submodule 解决多版本共存问题
不能。Worktree 解决的是「同一仓库内多个分支的本地开发隔离」，比如你在 payment-service 仓库里同时开 main 和 feature/refund-v2 两个工作区，避免 node_modules 冲突。但它不解决「跨仓库依赖版本锁定」问题。
如果你把 id-generator 克隆成独立 worktree，再把它软链接进 payment-service，那就退化成手动管理路径依赖，完全丢失 Git 的版本追溯能力。
真正需要的是：主项目知道它此刻依赖的是 id-generator 的哪个 commit，且这个关系能被 CI、部署、回滚全部识别——只有 submodule 或类似语义的依赖声明（如 monorepo 的 workspace protocol）能做到这点。
