如何用 Superpowers 的 Git Worktrees 实现多分支并行开发【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowersSuperpowers 是一个面向 AI 编程代理的技能框架其中的 using-git-worktrees 技能把 Git Worktrees 的工作树隔离流程自动化检测隔离环境、选定目录、安装依赖、跑基线测试最后按固定格式报告工作区就绪。这套流程针对的就是多分支并行开发里最费手工的那几件事。多分支并行的典型卡点stash 切了又切先说这一节要解决的问题同时推进两三个分支时传统的 stash 来回切为什么撑不住。还原一个很常见的场景主仓里正在写登录功能线上又冒出一个要今天修的 bug你自己还有个实验性重构不想污染当前分支。常规操作是 stash 来回切切完回来发现依赖目录被另一个分支的配置改了测试缓存也乱了stash 里攒着好几个没名字的现场每次 git checkout 都像在排雷。Git Worktrees 给这个问题的解法是同一个仓库只有一份 .git 对象库但可以挂多个工作目录每个目录钉死一个分支。你在 feature/auth 目录里动手feature/billing 目录完全不受影响也不必为每个分支重新 clone 一份仓库。手工敲 git worktree add 也能做到这一点但忽略校验、环境检测这些步骤全靠自觉。Superpowers 把整个生命周期拆成建、装、验、收四段每段写明了判定条件和兜底动作技能定义在 skills/using-git-worktrees/SKILL.md。下面按这四段拆开讲。 建三步完成工作树初始化这一节解决工作树往哪建、建之前该查什么。先确认自己是否已经在隔离环境里比较 git rev-parse --git-dir 和 --git-common-dir 两个值不相等说明你已经在 linked worktree 里直接跳到项目设置不要再套一层。这里有个隐蔽的坑——在 git submodule 里这两个值同样不相等所以文档专门加了一道子模块守卫防止把子模块误判成工作树。第二个判断是工具优先级如果当前代理环境自带原生工作树工具名字通常带 Worktree 字样优先用它。原生工具管目录放置、分支创建和清理绕过它直接敲 git 命令会造出环境看不见的幽灵状态这是文档里点名批评的第一号错误。目录按三条优先级选建前必过忽略校验选目录的顺序指令文件里声明过的偏好比如 CLAUDE.md 里写死了用哪个目录优先其次是项目里已存在的 .worktrees/ 或 worktrees/两个都在时隐藏目录胜出都没有就默认在仓库根建 .worktrees/。定下目录后有一道强制校验确认该目录已被 .gitignore 忽略校验命令是git check-ignore -q .worktrees文档对 worktrees 目录也给了同样的写法。没被忽略就先补规则并提交再创建。这一步防的是 Git Worktrees 最经典的事故——工作树目录本身被 git 跟踪随后把另一个分支的整棵代码树提交进了仓库。校验通过后核心动作一条命令git worktree add .worktrees/auth -b feature/authcd 进新目录隔离工作区就算建好了。遇到沙箱权限拦截导致创建失败时文档给的兜底是放弃建工作树直接在当前目录继续走装和验。装依赖安装按项目文件自动适配这一节解决新工作树里依赖怎么装——不靠记忆靠文件探测。技能按仓库根目录的标志性文件决定动作有 package.json 跑 npm install有 Cargo.toml 跑 cargo buildPython 项目看 requirements.txt 或 pyproject.toml 分别走 pip 或 poetry有 go.mod 跑 go mod download。探测不到对应文件就跳过不会硬套一条不存在的命令。这步不能省的原因工作树共享同一个 .git但工作目录是全新的node_modules、target 这类构建产物不会跟着分支走。跳过安装后面的基线测试根本没有运行条件。✅ 验基线测试把关确认工作树就绪这一节解决怎么判断工作区可以放心动手。依赖装完立刻跑一遍项目完整的测试套件npm test、cargo test、pytest 或 go test ./... 之类给新工作区立一个干净基线。全绿之后按固定格式报告就绪大致是三行Worktree ready at Tests passing (47 tests, 0 failures)Ready to implement 。基线测试如果有失败流程不会默认继续而是把失败摆出来问一句继续动手还是先查这个问题这不是流程洁癖——基线是脏的之后每出现一个测试失败你都得先分辨这是我改出来的还是本来就坏的调试成本会成倍放大。 收开发分支收尾时如何清理工作树这一节解决活干完了工作树和分支怎么处置。收尾走 finishing-a-development-branch 技能skills/finishing-a-development-branch/SKILL.md。先再跑一遍全量测试——合并前的绿才是数得上的绿——然后给三个选项本地合并回基础分支、推送并开 PR、原样保留稍后处理。走合并或明确丢弃这两条路径会触发清理git worktree remove 删工作树再跟一条 git worktree prune 清掉过期注册。走开 PR 则保留工作树因为评审意见还要在这个目录里改。清理有个边界只处理位于 .worktrees/ 或 worktrees/ 下的工作树宿主环境自己管理的工作区一律不碰。⚠️ 高频踩坑四个经典错误占了大多数这一节把两份技能文档点名的错误合并成一张清单都是实际流程里反复出现的。忘记校验 .gitignore。工作树目录没被忽略内容被意外跟踪。对策就是建目录前那次 check-ignore没通过就补规则再提交。凭肉眼判断我肯定不在工作树里。harness 建的隔离环境和子模块都会骗过目测两条 rev-parse 命令跑完就有结论。基线失败还往下走。这个测试本来就坏不能靠猜要么先修要么让用户明确拍板再继续。有原生工作树工具却直接敲 git 命令。绕过工具会留下它管不了的状态目录放哪、分支谁建、最后谁清理全部失控。进阶Git Worktrees 在 Superpowers 技能链里的位置这一节回答这套机制和哪些技能配合用。Git Worktrees 单独用只是省了切换时间Superpowers 的意图是把它嵌进完整开发流brainstorming 产出并确认设计后进入 using-git-worktrees 准备隔离工作区实现阶段交给 executing-plans 或 subagent-driven-development 在工作树里跑任务最后回到 finishing-a-development-branch 做合并和清理。整条链路里工作树在哪、基线是否干净、什么时候能删都有明确归属。想在自己的代理环境里试把仓库拉到本地即可git clone https://gitcode.com/GitHub_Trending/su/superpowers落地后的收益是具体的主仓不再被 stash 和频繁切换反复折腾每个功能分支有独立的目录、依赖和测试基线收尾时清楚该删什么、不该碰什么。建议从一个独立小功能起步完整走一遍建、装、验、收体会一下干净基线对失败归因的帮助。【免费下载链接】superpowersAn agentic skills framework software development methodology that works.项目地址: https://gitcode.com/GitHub_Trending/su/superpowers创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考