Appearance
Git 工作树让同一个仓库的多个分支同时处于不同的目录里，互不干扰。在 AI 辅助开发中，这意味着你可以让 AI 在一个独立目录里工作——它的改动不会出现在你当前的工作目录里，也不会污染主分支。完成后，如果结果满意就合并，不满意就直接删掉整个工作树，没有任何历史遗留。
using-git-worktrees：用 Git 工作树给 AI 提供隔离的开发空间
核心价值：多分支同时工作，互不干扰
普通的 Git 工作流里，切换分支意味着工作目录的内容也跟着变——你在 feature-A 分支上改了一半的代码，切到 hotfix 分支去修 bug，再切回来继续，虽然 Git 能保存状态，但整个工作目录的上下文已经切换了。
Git 工作树解决的正是这个问题：你可以同时检出多个分支，每个分支在一个独立的目录里，同时处于活跃状态。改 feature-A 的窗口和改 hotfix 的窗口可以同时打开，修改互不可见，文件系统层面完全隔离。
对 AI 辅助开发的意义
当你把一个功能任务交给 AI 时，AI 会读文件、改文件，这些改动会立刻出现在当前目录里。如果你同时还在用这个目录工作，两边的改动会相互混淆，也很难判断哪些是你改的、哪些是 AI 改的。
使用工作树之后，AI 在 .worktrees/feature-x/ 目录里工作，你在项目根目录工作，两边完全隔离。AI 的工作不会出现在你的 git diff 里，你的临时改动也不会影响 AI 的执行环境。
目录选择：按优先级决定，不要假设
创建工作树前，先确定把工作树放在哪里。按以下优先级检查：
第一优先级：检查项目里是否已有工作树目录
bash
ls -d .worktrees 2>/dev/null # 优先（隐藏目录）
ls -d worktrees 2>/dev/null # 备选如果已经存在，就用它。两个都存在时，.worktrees 优先。这样做的原因是保持与项目约定的一致性——项目里已有这个目录，说明团队已经在用它。
第二优先级：检查 CLAUDE.md 是否有偏好设置
bash
grep -i "worktree.*director" CLAUDE.md 2>/dev/null项目文档里如果指定了位置，直接用，不需要再问。
第三优先级：如果前两步都没有结论，问用户
选项通常是：
.worktrees/：项目本地，隐藏目录，随项目走~/.config/superpowers/worktrees/<项目名>/：全局位置，跨项目集中管理
安全验证：项目本地目录必须加入 .gitignore
如果选择在项目本地创建工作树目录（.worktrees 或 worktrees），在创建工作树之前，必须先确认这个目录被 .gitignore 忽略。
bash
git check-ignore -q .worktrees如果没有被忽略，后果很直接：工作树里的所有文件都会出现在 git status 里，一不小心就会被 git add . 批量提交进去，污染仓库历史。
发现没有被忽略时，立刻修复：把 .worktrees 加入 .gitignore，提交这个改动，然后再创建工作树。不要跳过这一步。
全局目录（~/.config/superpowers/worktrees/）在仓库外部，不需要做这个检查。
创建工作树的完整流程
确认了目录位置、验证了 .gitignore 之后，按以下步骤创建：
第一步：创建工作树并检出新分支
bash
git worktree add .worktrees/feature-x -b feature/x
cd .worktrees/feature-x第二步：自动检测并安装依赖
bash
# Node.js 项目
if [ -f package.json ]; then npm install; fi
# Rust 项目
if [ -f Cargo.toml ]; then cargo build; fi
# Python 项目
if [ -f requirements.txt ]; then pip install -r requirements.txt; fi根据项目类型自动判断，不要硬编码只支持某一种。
第三步：验证干净的基线
在工作树里跑一遍测试，确认从一个干净的起点开始：
bash
npm test # 或对应的测试命令如果测试在新建的工作树里就已经失败，说明主分支上本来就有问题，需要先向用户说明，再决定是否继续。不能带着已有的失败开始工作，否则后续无法区分哪些失败是你引入的、哪些是原本就有的。
完成后报告状态：工作树路径、测试通过情况、准备就绪的提示。
工作完成后的清理
工作树用完之后有两个选择：
保留：用
git worktree list可以看到所有工作树，分支和改动都在。如果工作结果满意，从主分支合并进来，然后用git worktree remove .worktrees/feature-x删除工作树目录。丢弃：如果结果不满意，直接删除工作树目录和对应的分支。代价极低，没有任何历史遗留，比
git reset --hard干净得多。
这种"低成本丢弃"的特性使得工作树特别适合 AI 任务：让 AI 在一个独立空间里尝试方案，看到结果再决定要不要合进来。
常见错误和对应的修复
跳过 .gitignore 验证：工作树内容出现在 git status 里，有被误提交的风险。修复：运行 git check-ignore，确认后再创建。
假设目录位置：在没有检查项目现有约定的情况下直接创建 .worktrees，与团队其他成员用的位置不一致。修复：按优先级检查，先看现有目录，再看 CLAUDE.md，最后才问。
带着失败的测试基线继续工作：后续出现问题时无法判断是新引入的还是原有的。修复：基线测试失败时停下来报告，获得明确指示后再继续。
只支持一种项目类型的依赖安装：在不同项目里复用时失效。修复：通过检测文件类型（package.json、Cargo.toml 等）自动判断。
FAQ
Q：工作树和 git stash + 切换分支的方式有什么本质区别？ A：git stash + 切换分支之后，工作目录的内容整体替换了，你只能看到当前分支的状态。工作树是两个目录同时存在，你可以用两个终端窗口或编辑器窗口同时打开，并排工作，互不影响。对 AI 来说，这意味着 AI 改文件和你改文件可以同时进行，在文件系统层面完全隔离。
Q：一个仓库可以有多少个工作树？ A：没有硬性限制。每个工作树对应一个分支，同一个分支不能被多个工作树同时检出。实际使用中，通常 2 到 4 个就足够了，太多会增加管理负担。
Q：工作树里的改动会影响主仓库的 git log 吗？ A：不会。工作树里的提交会记录在对应的分支上，在你合并到主分支之前，主分支的历史不受影响。如果最终决定丢弃工作树，删除分支即可，主分支完全干净。