报错“working tree 'xxx' already exists”是因为.git/worktrees/下残留同名元数据；应先git worktree list查看，再用git worktree remove 清理，确保目标路径为空且注意windows路径格式。
git worktree add 为什么报错“working tree 'xxx' already exists”
这是最常卡住人的第一步：想给同一个仓库加第二个工作树，但 git worktree add 直接拒绝。根本原因不是路径冲突，而是 Git 已经在 .git/worktrees/ 下记录了同名工作树（比如你之前删过目录但没用 git worktree remove 清理元数据）。
实操建议：
- 先运行
git worktree list看当前注册的所有工作树，确认是否残留了已删除目录的记录 - 如果确实残留，用
git worktree remove <path></path>（哪怕目录已不存在）来清理元数据；不要手动删.git/worktrees/下的子目录 - 确保目标路径完全为空——Git 不会覆盖非空目录，哪怕里面只有
.DS_Store或.gitignore也会报错 - Windows 用户注意路径分隔符，
git worktree add C:\dev\myproj-fix比C:/dev/myproj-fix更稳
多个 worktree 共享 stash 吗？怎么避免分支切换互相干扰
不共享。每个 worktree 有独立的 HEAD、独立的暂存区和工作目录，但共用同一个 .git 目录下的对象库和 reflog。stash 是绑定到具体工作树的（底层存在 .git/worktrees/<name>/refs/stash</name>），所以你在 A 目录 git stash，B 目录是看不到的。
但干扰依然存在：
- 所有 worktree 共享同一份
refs/heads/，你在 A 目录git checkout -b feat/new，B 目录立刻能git checkout feat/new - 如果两个 worktree 同时 checkout 到同一分支，又各自 commit，reflog 会混在一起，
git reflog输出里看不出是谁提交的 -
git clean -fd在任一 worktree 执行，都会删掉其他 worktree 目录里未被 Git 跟踪的文件（因为它们共享同一份git status视图）
worktree 和 submodule 混用会出什么问题
会触发 Git 的“嵌套 Git 仓库检测”，导致子模块目录被当成独立仓库处理，常见表现是：git status 显示子模块为 “modified: xxx (new commits)” 即使你没动它，或者 git add 失败并提示 “Path 'xxx' is in submodule 'xxx'”。
关键点在于：worktree 的 .git 是文件（指向主仓库 .git/worktrees/xxx/gitdir），而 submodule 的 .git 是目录。当 worktree 目录下有 submodule 时，Git 容易误判 .git 文件和 submodule 内的 .git/ 目录关系。
稳妥做法：
- 避免在 worktree 根目录下直接 clone submodule；改用
git submodule add --depth=1并确保主仓库已 commit submodule 引用 - 如果必须调试 submodule，单独为它建一个 worktree：
git -C path/to/submodule worktree add ../submodule-debug - 不要在 worktree 里执行
git submodule update --init --recursive后再做git worktree add—— 初始化过程可能污染 .git 文件结构
CI/CD 中用 worktree 部署多环境，要注意哪些硬限制
CI 环境通常禁止写入主仓库的 .git 目录（比如只读挂载或容器临时文件系统），而 git worktree 必须往 .git/worktrees/ 写元数据。一旦失败，git worktree list 就会漏掉条目，后续 remove 或 prune 都不可靠。
更隐蔽的问题是钩子（hook）行为不一致：主工作树的 pre-commit 不会在 worktree 中自动生效，因为 Git 只读取 .git/hooks/，而 worktree 的 hook 是软链接或复制而来，CI 模板若用 git clone --shared 可能导致 hooks 权限丢失。
生产级建议：
- CI 中优先用
git clone --reference+ 独立目录，而非worktree；worktree 更适合开发者本地快速切上下文 - 如果坚持用，部署前务必加
git worktree prune --expire=now清理僵尸记录 - 永远不要在 CI 脚本里用
git worktree add --detach后直接git checkout—— detached HEAD 下的 worktree 无法被git worktree list正确识别为“已检出分支”
worktree 的本质是“轻量级克隆”，但它不是完全隔离的沙盒。分支、reflog、对象库存、甚至 fsync 行为都可能跨 tree 波动，真正要隔离，还是得靠 clone 或容器。
