git worktree是大型单体仓库多分支构建提速最直接有效的原生方案，通过共享.git数据库、隔离工作目录实现并行构建耗时下降60%以上，无需改ci配置、不引入新工具链、不复制.git数据。
Git worktree 是大型单体仓库多分支构建提速最直接有效的原生方案，不需要改 CI 配置、不引入新工具链、不复制 .git 数据，只需合理组织工作树路径即可让并行构建耗时下降 60% 以上。
git worktree add 创建工作树时路径必须是绝对路径或相对于主仓库根目录的相对路径
很多团队在 CI 脚本里写 git worktree add ./feature-build feature-branch，结果在不同工作目录下执行失败——因为 git worktree add 的第一个参数（路径）是相对于当前 shell 工作目录的，不是相对于 Git 仓库根目录。CI 环境中 $PWD 经常变化，容易误建到临时目录甚至覆盖已有文件。
- ✅ 正确做法：用
$(git rev-parse --show-toplevel)获取仓库根路径，再拼接子目录，例如：git worktree add "$(git rev-parse --show-toplevel)/../build-feature" feature-branch - ⚠️ 注意：路径不能与现有工作树重叠，也不能是主工作树所在目录的子目录（Git 会拒绝）
- ? 如果构建脚本运行在 Docker 容器内，确保挂载宿主机路径时，该路径在容器内可写且不与 /tmp 或 /var/run 冲突
CI 中并行构建多个分支时，worktree 的 .git 文件是符号链接，但 git gc 不会跨工作树清理
每个工作树的 .git 实际是一个指向主仓库 .git/worktrees/<name></name> 的符号链接，所有对象数据库共享。这意味着你不能在某个工作树里执行 git gc 来“优化自己”，它只影响主仓库的打包行为。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- ❌ 错误认知：“我在 feature-worktree 里跑
git gc能加快这个分支的构建”——无效，且可能干扰主仓库 GC 状态 - ✅ 正确做法：统一在主工作树执行
git gc --prune=now（建议每周一次），或配置gc.auto = 1000让 Git 自动触发 - ⚠️ 构建镜像时若使用
docker build -f Dockerfile .，确保上下文（.）不包含其他工作树目录，否则会把整个../build-hotfix打包进镜像，显著增大构建上下文体积
大型仓库中 worktree + pnpm/npm link 导致 node_modules 冲突的典型表现
当多个工作树共用同一 node_modules（比如通过 pnpm store 共享或软链接复用），不同分支的 lockfile 差异会导致构建产物不一致，甚至 Cannot find module 'xxx' 错误。
- ✅ 推荐方式：每个工作树独立安装依赖，用
pnpm install --no-frozen-lockfile（避免因 lockfile 差异被拒绝安装） - ⚠️ 不要手动
ln -s共享node_modules目录——pnpm 的硬链接机制依赖于 workspace 根路径和 lockfile 一致性，跨工作树破坏此假设 - ? 在 CI 中可缓存
~/.pnpm-store，但每个工作树仍需单独执行pnpm install，保证node_modules/.pnpm下的符号链接指向正确版本
真正卡住构建速度的，往往不是 Git 本身，而是构建系统反复重建依赖、重编译、重解析 TypeScript 类型。worktree 解决的是“状态隔离”问题，但它不会自动帮你解决 tsconfig.json 路径映射冲突、webpack resolve.alias 指向错误，或 monorepo 中 packages/ 子路径未同步更新的问题——这些得靠明确的构建上下文约束，而不是靠“多开几个目录”来掩盖。
