Superpowers + Git Worktrees 完整指南:5 步建好隔离工作树,一条命令完成清理

发布时间:2026/8/28 11:42:32
Superpowers + Git Worktrees 完整指南:5 步建好隔离工作树,一条命令完成清理 Superpowers Git Worktrees 完整指南5 步建好隔离工作树一条命令完成清理【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers同时推进多个功能时分支切换是最贵的一笔隐形成本环境被污染、依赖要重装、上下文被打断。Superpowers 的 using-git-worktrees 技能把 Git Worktrees 包成一套固定的自动化流程——自动检测目录位置、验证忽略规则、按项目类型装依赖、跑基线测试——你只需要等一句三行的工作树就绪报告就能开工。这里拆解它的判定机制、走一遍完整流程并附上避坑清单。 并行开发的隐形成本分支切换到底贵在哪真正的开销不在git checkout本身而在它带动的环境与状态。反复切换分支通常意味着多个功能无法真正同时推进只能轮流占用同一个工作目录每个功能的依赖、构建产物互相覆盖环境边界模糊新分支要重新装依赖、重新配置等待时间全部浪费未提交的改动可能被带进另一个分支冲突从可能变成经常Git Worktrees 让一个仓库同时挂出多个工作目录各自绑定一条分支目录之间完全隔离。但原生命令只解决目录建出来了不解决环境能用起来——依赖装没装、测试基线是不是绿的它一概不管。Superpowers 把这整串动作固化成流程入口在技能定义文件skills/using-git-worktrees/SKILL.md下面先看它怎么替你做决定。 目录落在哪里工作树三级优先级与忽略规则验证创建流程的第一个决策不是建工作树而是确定新工作树放在哪里。Superpowers 不随机选路径而是按固定顺序走三级判定现有目录检查项目里是否已经有.worktrees隐藏目录或worktrees目录有就直接用两个同时存在时.worktrees优先。配置文件没有现成目录时查看CLAUDE.md等指令文件里是否声明了工作树位置偏好声明过的直接照办。询问用户两条线索都没有就友好地问一次用户偏好并把答案沿用下去。目录定了之后不能立刻动手。还有一个必须先回答的问题这个目录有没有被 Git 忽略没被忽略的话工作树里的依赖和构建产物会全部以未跟踪文件的形式出现在git status里一次不小心的全量提交就把整棵工作树带进了仓库。所以流程里有一道硬性验证git check-ignore -q .worktrees 2/dev/null || git check-ignore -q worktrees 2/dev/null这条命令让 Git 自己回答目标目录在不在忽略清单里返回码非零就说明没忽略。此时 Superpowers 会先把目录补进.gitignore并提交这条改动再继续往下走——这一步拦截的是工作树内容污染仓库这个最高频的事故。 实战演练从空目录到基线全绿的 5 步位置与忽略规则都敲定后创建过程本身只有 5 步。Agent 会在流程开头宣布正在使用 using-git-worktrees 技能然后按序执行。第 1 步自动检测与准备流程先回答两个问题目录放哪、是否已被忽略。也就是上一节的三级优先级加忽略验证已有目录通过检查就直接进入创建环节若目录没被忽略先补.gitignore提交再往下。两个问题都通过后真正落地的动作只有一条命令。第 2 步创建工作树先取一下项目根目录名后面拼路径会用到任何时候都可以这样查看project$(basename $(git rev-parse --show-toplevel))接着创建工作树并切进去git worktree add $path -b $BRANCH_NAME cd $pathgit worktree add会在主仓库之外生成一个独立工作目录与主仓库共享对象库不需要重复克隆整个仓库cd之后后续所有命令都发生在新工作空间里。第 3 步按项目类型自动装依赖工作树建好了但里面的代码只是同一份代码每个工作树都需要自己的依赖环境。Superpowers 靠探测特征文件来决定跑什么if [ -f package.json ]; then npm install; fi if [ -f Cargo.toml ]; then cargo build; fi if [ -f requirements.txt ]; then pip install -r requirements.txt; fi if [ -f pyproject.toml ]; then poetry install; fi if [ -f go.mod ]; then go mod download; fi每个分支都是文件存在才执行的模式纯 Go 仓库只会触发go mod download纯 Rust 仓库只会触发cargo build不存在的特征文件对应的分支直接被跳过。第 4 步基线测试验证依赖就绪不等于可用代码本身得先能跑绿。这里对项目跑一次完整测试套件——Node.js 对应npm testRust 是cargo testPython 用pytestGo 则是go test ./...——在写任何新代码之前确立基线。这一步的意义在于归因此刻若已有测试失败说明是历史遗留问题而不是工作树引入的跳过它之后看到的每一次红都说不清是谁的锅。第 5 步报告就绪基线确立后最后一步是把状态收敛成固定格式的三行报告Worktree ready at full-path Tests passing (N tests, 0 failures) Ready to implement feature-name第一行给出进入路径第二行用测试数量确认基线干净第三行是可以开工的信号。把整个过程放进一次完整会话里看大致长这样用户开始做登录模块给我个隔离环境 Agentusing-git-worktrees 技能准备隔离工作空间 → 项目已有 .worktrees/忽略规则验证通过 → 创建 login 工作树绑定 feature/login 分支 → 探测到 package.json依赖安装完成 → 全量测试执行47 通过0 失败 Worktree ready at /home/lin/myproject/.worktrees/login Tests passing (47 tests, 0 failures) Ready to implement login feature 场景速查各种情形下 Agent 分别做什么完整流程的决策分支有限下面这张表覆盖了实际使用中最常遇到的情形方便你快速对号入座或审计 Agent 行为当前情形Agent 的动作已有.worktrees/目录直接复用但仍先跑一次忽略验证已有worktrees/目录同上两个目录同时存在选.worktrees/两个目录都不存在查CLAUDE.md声明没有就询问用户目标目录未被 Git 忽略自动补进.gitignore并提交基线测试失败列出失败项询问是否继续探测不到依赖文件跳过依赖安装直接进测试环节 收尾开发完成后如何清理工作树工作树不是建完就不管收尾方式同样是固定的。功能做完、测试转绿之后由 finishing-a-development-branch 技能skills/finishing-a-development-branch/SKILL.md接管。先用 list 确认当前分支对应哪个工作树git worktree list | grep $(git branch --show-current)git worktree list会打印全部工作树及其分支的对照表grep 过滤出当前分支所在的那一行删哪个目录一目了然。确认后执行删除git worktree remove worktree-path路径参数就是上一步的输出执行后该目录从磁盘移除Git 侧的注册信息一并回收。这套建—用—清的闭环并不孤立brainstorming 在设计获批后会自动调用它准备实现工作空间executing-plans 和 subagent-driven-development 在工作树里执行开发任务finishing-a-development-branch 则负责最后的收尾——四个技能串成一条流水线全程不需要你手工管理目录。⚠️ 避坑清单4 个最容易犯的错这套流程的每条规则都在拦截真实事故以下四项可以当作自查清单无论是自己实现类似机制还是审查 Agent 的执行过程都适用。跳过忽略验证工作树内容被 Git 跟踪git status被整目录污染。流程用强制的git check-ignore检查拦截即使目录看起来已被忽略也不跳过。假设目录位置项目明明在用worktrees你却新建了.worktrees两套并存后维护者会混乱。始终按现有目录 → 配置文件声明 → 询问用户的顺序决策不靠猜。带着失败的基线继续开发后续每次测试红了都无法归因分不清是新 bug 还是旧账。流程的规矩是报告失败并征求确认而不是静默继续。硬编码环境准备命令在 Rust 仓库上跑npm install只会立刻失败。一切以特征文件探测为前提依赖安装命令都遵循文件存在才执行的模式。 延伸材料从技能源码到测试脚本以上两个技能的文件都是纯 Markdown想核对实现细节或扩展流程直接读源码即可工作空间建立流程在skills/using-git-worktrees/SKILL.md收尾流程在skills/finishing-a-development-branch/SKILL.md。验证行为是否按预期运转可以看技能测试入口tests/claude-code/run-skill-tests.sh以及与子代理开发流程的集成测试tests/claude-code/test-subagent-driven-development-integration.sh。本地还没有仓库的话先克隆一份git clone https://gitcode.com/GitHub_Trending/su/superpowers克隆完成后上面的路径在仓库根目录下可以直接定位到。工作树解决的是并行Superpowers 叠加的价值在于把准备、基线、清理这三项隐性成本变成可验证的自动动作。你不再需要记住上一个功能做到哪个分支、新目录里依赖装没装开工前等一句绿色报告完工后把工作树交给清理技能仓库始终处于干净状态。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

相关新闻