07_gstack并行开发Git Worktrees与Conductor多会话管理关键字gstack、Git Worktrees、Conductor、并行开发、多会话管理、Claude Code、并行sprint、Garry Tan、AI并行工作流“One sprint, one person, one feature — that takes about 30 minutes with gstack.”这句话说完Garry Tan 停顿了一下然后加了一句“But here’s what changes everything: you can run 10-15 of these sprints in parallel.”这是 gstack 和所有其他 AI 辅助开发工具之间最本质的差别。不是单个任务跑得更快而是任务并行数量的量级提升。一、并行开发的物理限制在 AI 辅助开发之前并行开发受制于一个物理限制一个工程师的注意力是串行的。你可以同时开 10 个分支但同一时刻你只能专注于一个。切换上下文有认知成本切换代码库也有时间成本stash、checkout、等 IDE 重新索引……。AI 不受这个限制。Claude 可以同时在 15 个不同的上下文里工作每个上下文都有完整的注意力。问题是如何让 15 个 Claude 会话同时高效工作而不是互相干扰这就是 Git Worktrees Conductor 要解决的问题。二、Git Worktrees让多分支并行成为可能Git Worktrees 是 Git 2.5 引入的特性允许同一个仓库的多个分支同时以独立目录的形式存在于文件系统中。传统多分支切换 main/ 唯一的工作目录 git checkout feature-a -- 切换IDE重新加载 git checkout feature-b -- 再切换IDE再重新加载 git checkout feature-c -- 再切换...... 问题单次切换30-60秒10个分支来回切换 工程师大量等待 Git Worktrees 方案 project-main/ main 分支只读不改动 project-feature-export/ CSV导出功能 project-feature-auth/ OAuth集成 project-feature-dashboard/ 数据看板重设计 project-feature-api/ API v2 接口 project-feature-mobile/ 移动端适配 ...同时存在于文件系统互相独立 每个目录都是完整的工作空间拥有独立的 - 文件状态 - IDE 索引 - 编译缓存 - 测试结果Worktrees 的配置# 创建主仓库gitclone https://github.com/team/app project-main# 为每个功能创建独立工作树cdproject-maingitworktreeadd../project-feature-export feature/export-csvgitworktreeadd../project-feature-auth feature/oauth-integrationgitworktreeadd../project-feature-dashboard feature/dashboard-v2# 每个工作树都是完整的 Git 仓库视图ls../# project-main/# project-feature-export/# project-feature-auth/# project-feature-dashboard/现在15 个分支可以同时在文件系统上以独立目录存在没有切换成本没有文件冲突。三、Conductor协调多个 Claude 会话Git Worktrees 解决了多分支共存的问题Conductor 解决了多个 Claude 会话如何协调工作的问题。Conductor 的架构模型 -------------------------------------------- | Conductor 控制层 | | | | 会话注册表 | | session-01: feature-export, /plan-eng-review (运行中) | session-02: feature-auth, 编码实现 (运行中) | session-03: feature-dashboard, /qa (运行中) | session-04: feature-api, /review (等待) | session-05: feature-mobile, 等待启动 | ... | | | | 状态跟踪每个会话的当前阶段 | | 资源调度根据系统负载调整并发数 | -------------------------------------------- | | 管理 N 个并行会话 v ------ ------ ------ ------ |会话01| |会话02| |会话03| |会话04| | | | | | | | | |feature| |feature| |feature| |feature| |export| |auth | |dash | |api | ------ ------ ------ ------Conductor 不是简单的任务队列它理解 gstack 的 Skill 系统知道每个 Skill 的执行时间、资源需求、以及下游依赖关系。3.1 智能调度/qa 要调用持久化浏览器守护进程 -- Conductor 确保同一时刻只有一个 /qa 在用浏览器 -- 其他 /qa 请求排队等待 /review 不需要浏览器 -- 可以与 /qa 并行运行 /plan-ceo-review 和 /plan-eng-review 是顺序依赖 -- Conductor 自动建立依赖关系确保顺序执行3.2 状态持久化每个会话的状态持久化到磁盘 .claude/sessions/feature-export.json .claude/sessions/feature-auth.json ... 内容包括 - 当前执行阶段 - 已完成的 Skill - 待处理的 [ASK] 问题 - 测试结果摘要 工程师可以随时查看所有会话的状态 也可以在任意时间介入任意会话。四、Garry Tan 的并行工作流Garry Tan 公开分享过他的日常工作方式是理解 gstack 并行价值的最好样本早上09:00-10:00启动所有 sprint打开 project-main/ 识别今天要做的 10-15 个功能 通过 Conductor 批量启动 /conductor start feature-export feature-auth feature-dashboard ... | v 每个 sprint 的启动序列异步并行 1. /plan-ceo-review -- 确认方向2分钟 2. /plan-eng-review -- 锁定架构4分钟 3. Claude 编码 -- 自动实现8分钟 约 30 分钟后10-15 个功能全部到达编码完成状态 等待 /review 和 /qa下午14:00-16:00审查所有 PR/conductor status -- 查看所有会话状态 --------------------------------------- | feature-export [REVIEW_NEEDED] | | 2 个 [ASK] 等待确认 | --------------------------------------- | feature-auth [QA_FAILED] | | 路径03: OAuth 回调 URL 错误 | --------------------------------------- | feature-dashboard [READY_TO_SHIP] | | 测试全通过文档已更新 | --------------------------------------- | feature-api [CODING] | | 预计 12 分钟后完成 | --------------------------------------- 处理 [ASK] 问题Garry 的时间投入最多1分钟/问题 合并所有 [READY_TO_SHIP] 的 PR晚上20:00-21:00收尾修复白天发现的 [QA_FAILED] 问题 通过 Conductor 启动被阻塞的 sprint 批量 merge 所有已通过的 PR /retro 跑一下日度数据总结这个工作流的结果Garry 每天做的主动决策不超过 2~3 小时但同时推进了 10-15 个功能的完整生命周期。五、并行开发的注意事项并行不是银弹用不好会变成并行混乱。以下是实际使用中需要注意的点5.1 功能独立性原则适合并行的功能 - 不同功能模块导出/认证/看板 - 不修改同一个核心文件 - 数据库表不重叠 不适合并行的功能 - 共享核心 utils 函数 - 修改同一张数据库表的结构 - 有明确的先后依赖关系 判断方法 /plan-eng-review 输出的边界定义会告诉你 这个功能的改动范围据此判断并发冲突风险5.2 合并策略每天晚上合并时的推荐顺序 1. 先合并无依赖的独立功能 2. 有依赖的功能在依赖项合并后重新 rebase 3. 修改了共享文件的功能串行合并 Conductor 会自动跟踪依赖关系 提示你最优的合并顺序。5.3 并发数的上限系统资源参考配置 16GB 内存建议最多 6-8 个并发会话 32GB 内存10-15 个并发会话 注意 每个活跃的 /qa 会话会占用一个 Chromium 进程约 300MB 多个 /qa 并发时建议 Conductor 串行调度浏览器任务六、单人团队 vs 多人团队的使用差异单人团队创始人模式早上启动今天的 10-15 个 sprint 下午处理 [ASK] 问题审批 PR 晚上合并规划明天 角色工程师是决策者Claude 是执行者 价值一个工程师的实际吞吐量 × 10-15多人团队每个工程师维护自己的 Conductor 会话 团队共享 .claude/skills/gstack 配置 协作方式 - 每个人的 /retro 数据汇总到团队看板 - 并行 sprint 的代码审查仍由人完成 - /review 的 [AUTO-FIXED] 减少低价值的 review 评论 价值统一团队的工程质量标准减少 review 摩擦七、一个思维转变使用并行开发之前工程师思考问题的粒度是“今天能完成哪个功能”使用并行开发之后思考粒度变成了“今天要推进哪 15 个功能”这个粒度的转变不是工程效率的线性提升而是工程心理的根本变化功能变多了但每个功能的心理负担变小了。不再纠结于这个功能要做多久因为 30 分钟的 sprint 让时间成本变得可预期。不再担心做这个就耽误了那个因为并行让顺序决策变成了并发决策。这才是 Garry Tan 能在 60 天里完成 60 万行代码的根本原因——不是工作时间更长而是工作方式从串行变成了并行。下一篇我们进入企业级话题gstack 的安全机制、监控治理、以及如何在团队里推广和维护一套统一的 gstack 配置。系列文章本文是 gstack 深度解析系列第 07 篇共 10 篇。参考资料Git Worktrees 官方文档、gstack Conductor 源码、Garry Tan 公开演讲实录