用Git Worktree和Rust工具管理并行Claude Code会话

同时开 10 个 Claude Code 这事儿听起来很爽真干起来很崩溃。我最开始就是简单地开 10 个终端窗口往同一个项目目录里一戳然后给每个会话派不同的任务。结果半小时之后整个工作区彻底失控A 会话改的文件被 B 会话的自动重构覆盖掉C 会话读到了一个 D 会话刚生成的临时文件然后一本正经地问我项目里怎么会有这么奇怪的东西。最要命的是当 10 个会话同时在同一个 Git 分支上提交那堆交错的历史让我回滚都不知道从哪儿下手。后来我认真用起了 Git Worktree问题才算从根上解决。但 Worktree 原生命令有个尴尬的地方——它好用但烦人。创建要敲一长串参数目录命名靠手动干完活还得记得清理时间一长 worktree 列表里堆了一堆不知道是干嘛的分支。于是我用 Rust 写了 1000 来行的小工具把这些琐碎操作全包了。这篇文章就是完整分享我踩过的坑、工具的设计思路、关键代码以及从 0 到 10 个会话并行跑起来的全部实操过程。1. 为什么 10 个 Claude Code 会打架并行 AI 编码的真实痛点1.1 多会话并行并不是多开几个终端那么简单很多人的第一反应是多开会话有什么难的多开几个终端窗口不就行了问题在于Claude Code 这类命令行 AI 编程工具的上下文边界是整个当前工作目录。它读的是目录里的源码、配置、文档写的是目录里的文件。如果你开 10 个会话全都指向同一个目录那这 10 个会话其实共享同一个文件系统、同一个 Git 状态。我举个例子你就明白了。假设我给会话 A 派了个重构任务把用户模块的接口从回调改成 async/await。给会话 B 派了个修复登录超时 bug。这俩任务表面上看互不相关但它们在同一个工作区里跑的时候A 可能在重构的过程中新建了一个api/types.tsB 的会话读目录时发现了这个新文件可能会误以为这是已有代码结构的一部分然后基于一个半成品开始改逻辑。等两个会话都提交代码已经不知道被串改成什么样了。更常见的坑是两个会话同时改同一个文件。Claude Code 的底层操作逻辑是逐段读文件、逐段改写不是并发安全的。两个会话同时盯上auth.ts你这边看到的是 A 改好了登录逻辑再切到 B 一看B 又把整个文件重写了一遍把 A 的改动覆盖得干干净净。这种互相踩踏比人工开发时的 merge conflict 糟糕得多因为你甚至没有机会 resolve——改动是在 AI 的工作区里直接被覆盖掉的你连冲突提示都看不到。1.2 上下文污染AI 会话会被别人的临时文件带偏文件互相覆盖是打架的一种另一种更隐蔽的伤害是上下文污染。Claude Code 在决策时会扫描当前目录树读取它认为相关的文件。如果同一个目录里同时存在多个并行会话产生的临时文件、实验性脚本、未完成的迁移记录AI 很容易把这些别人家的半成品当成项目自身的一部分。我遇到过最离谱的一次一个会话来处理前端样式问题结果它在工作区里发现了一个由另一个会话生成的data/migration.sql于是煞有介事地开始分析项目里为什么会有数据库迁移脚本还提出了一堆跟任务毫无关系的建议。这就是典型的上下文污染——AI 太听话了它会认真对待工作区里的每一个文件。有些人想靠在一个仓库里开不同的分支来解决。这个思路方向对但只做了一半。分支隔离的是提交历史隔离不了工作目录。你git checkout feature-a之后工作区里就是 feature-a 的内容但你没法同时在同一个工作区里切到 feature-b。也就是说分支切换是串行的你切到 B 时 A 的工作区内容就被挤走了。而 Claude Code 会话一旦开始执行任务需要工作区保持稳定你不能让它干到一半把底层文件全换掉。这就引出 Git Worktree 的真正价值。1.3 一个反直觉的事实AI 编程越强大工作区隔离越重要模型能力越强单次任务能干的活越多你就越想给它派大任务。任务一大并行需求就越强。你会发现自己在同时推进一个重构、一个新功能、一个 bug fix、一个依赖升级……如果这些任务全塞在同一个工作区里AI 越强大相互之间的破坏力就越强。所以我把这句话写在工位上AI 编程时代隔离的不是人是上下文。每一份独立任务必须有一份独立的工作目录、一条独立的分支、一个独立的会话。目录-分支-会话三者一一对应这是多 AI 并行的黄金法则。剩下的问题只有一个怎么把这件事做得干净利落不给人添麻烦。2. Git Worktree 的原理同一个仓库N 个互不干扰的工作区间2.1 一个 .git多个工作目录Git Worktree 是 Git 2.5 引入的功能核心思路一句话一个仓库可以同时关联多个工作目录每个工作目录检出不同的分支彼此独立提交互不干扰。普通情况下你的仓库只有一个工作目录那个目录下面有个.git目录里面存着全部版本数据。git worktree add会创建一个新目录然后在这个新目录里生成一个.git文件注意是文件不是目录这个文件的内容只有一行指向主仓库.git/worktrees/名称目录。这个worktrees子目录记录了这个附加工作树的分支、HEAD、index 等信息。理解了底层的.git文件与.git/worktrees目录结构后你就明白了为什么 Worktree 之间互不干扰它们共享同一份对象数据库commit、tree、blob但索引、HEAD、暂存区各自独立。一个工作树的提交不会影响另一个工作树的文件状态这就给多个 Claude Code 会话提供了完美的物理隔离。每个会话打开一个 worktree 目录看到的世界完全不一样。但这里有个容易被忽略的限制同一个分支不能同时被两个 worktree 检出。Git 会通过 worktree 元数据做锁检测你尝试在第二个 worktree 里git checkout main会直接报错。这其实是个保护机制它防止两个工作树共享同一分支导致列表互相覆盖。所以实践中每个 worktree 对应一个独立特性分支主分支main只作为最终合并的接收方。2.2 三个最常用的 Worktree 命令用 Worktree 日常无非三件事建、看、删。对应的原生命令是# 创建新目录 新分支一步到位 git worktree add ../cc-fix-login -b fix/login-timeout # 查看列出所有 worktree 及其分支、路径 git worktree list # 删除先确保该 worktree 没有未提交改动 git worktree remove ../cc-fix-login # 清理删除 worktree 后顺便清理失效的元数据 git worktree prune这几个命令本身不难难在状态管理。一个 worktree 对应哪个任务它是在哪个 commit 上创建的任务进行到一半我把它忘了过几天还能不能想起来这是干什么的原生命令不会帮你在git worktree list里写注释所有语义信息全靠目录名硬编码。目录命名这件事一旦人工来做就会出现a、b、test2、最终版3这类末日命名法。2.3 Worktree 的边界为什么它好用但烦人Git Worktree 是个好功能但它始终停留在Git 命令的层面没有上升到开发者工作流的层面。你需要自己决定目录建在哪里、怎么命名、要不要装依赖、装完依赖会不会和别的 worktree 串、这个 worktree 的分支落后主线多少、干完活要不要提醒自己合并……这些琐碎的事情一件一件都不算难但叠在一起就让人觉得用 Worktree 好累。我当时的状态是知道它是正确的方案但每次要用都得在心里过一遍那一串流程稍一忙就放弃了回到10 个终端怼同一个目录的老路。这就是我标题里说救活的原因——光有 Git Worktree 还不行得有个工具把这套流程自动化让人只需要想我在干什么任务而不用想git 的命令该怎么敲。3. 用 Rust 写一个 Worktree 管理工具核心设计与关键代码3.1 为什么选 Rust启动快、零依赖、单体二进制的价值这个工具本质上是胶水解析几个子命令、拼一串 git 命令、调进程、读输出、维护一个任务清单记录。这类工具用脚本语言写很常见但用起来有几个烦心事Node 写的工具要先装 Node 环境Python 写的工具要处理解释器版本和依赖而且启动延迟都在一两百毫秒以上。这个工具的使用频率很高——每次新建会话都要敲一次如果每次都要等个一两秒才有反馈人会很难受。Rust 编译出来的二进制在 macOS 上通常只有几百 KB 到 1MB 多启动时间是毫秒级还没有任何运行时依赖。cargo build --release产出一个文件拷到任意机器上都能跑。再加上 Rust 的静态链接特性不用担心目标机器上缺什么动态库。对这种高频使用的小工具来说启动速度和使用顺滑度就是天花板Rust 在这点上几乎是完美的选择。不需要 Tauri、不需要 egui 这类 GUI 框架纯 CLI 就行。CLI 工具有个天然优势可以很好地嵌入到 Claude Code 的工作流里。我可以在 worktree 里让 Claude Code 直接调用我编译好的工具去查询状态、补全上下文AI 也能用。这个后面详细说。3.2 工具功能清单与命令设计我的这个工具叫cc-worktree核心命令分为五类对应整个生命周期# 1. 创建根据任务名生成 worktree自动装依赖自动启动会话 cc-worktree add fix-login-timeout # 2. 查看列出所有 worktree 和对应任务状态 cc-worktree list # 3. 记录把当前 worktree 的任务描述、会话信息写进清单 cc-worktree note 正在处理登录超时主要改 auth.ts # 4. 完成合并分支回 main并清理 worktree cc-worktree done fix-login-timeout # 5. 汇总如果 worktree 分支落后 main提醒我同步 cc-worktree status命令设计的原则是动词优先、名词是任务。add、list、done、status都是英语使用者最熟悉的动作后面跟任务名而不是跟目录名或哈希值。这样大脑负担最小肌肉记忆形成之后几乎不需要思考。为什么不做成交互式 TUI因为交互式界面在终端里看着炫但你没法让 AI 调用它。CLI 的一个核心优势就是可脚本化、可组合。Claude Code 可以在会话里调用它可以把它的输出当成项目状态的一部分。这让工具从一个人用的工具升级成了人和 AI 共用的协作工具。3.3 关键实现调用 git、目录命名、任务登记先看项目结构。标准 Rust 项目依赖很少[package] name cc-worktree version 0.1.0 edition 2021 [dependencies] clap { version 4, features [derive] } anyhow 1 chrono 0.4 serde { version 1, features [derive] } serde_json 1clap负责命令行解析anyhow统一错误处理chrono生成时间戳serde做任务清单的持久化。总共五个依赖全部是常用的基础库没有任何花活。核心代码的骨架是 Clap 的 derive 模式use clap::{Parser, Subcommand}; #[derive(Parser)] #[command(name cc-worktree, about Claude Code 并行会话的 Worktree 管理工具)] struct Cli { #[command(subcommand)] command: Commands, } #[derive(Subcommand)] enum Commands { /// 新建一个与任务绑定的 worktree并自动安装依赖 Add { /// 任务名比如 fix-login-timeout #[arg(value_name TASK)] task: String, }, /// 列出全部 worktree 及对应任务 List, /// 记录当前 worktree 的任务说明 Note { #[arg(value_name TEXT)] text: String, }, /// 合并指定任务分支到 main 并清理 worktree Done { #[arg(value_name TASK)] task: String, }, /// 检查各 worktree 分支与本线主分支的落后情况 Status, }创建 worktree 的操作涉及三件事目录命名、创建分支、登记清单。目录命名我做了个约束cc-任务名-短时间戳。任务名在前面方便一眼看出这个 worktree 是干嘛的时间戳在后面防止同名任务重复创建时目录冲突。举个例子cc-worktree add fix-login-timeout会生成cc-fix-login-timeout-20250617。创建的核心逻辑fn create_worktree(task: str) - Result() { let branch format!(cc/{}, task); let dir format!(../cc-{}-{}, task, chrono::Local::now().format(%Y%m%d%H%M)); // 1. 创建 worktree新目录 新分支 run_git([worktree, add, -b, branch, dir])?; // 2. 自动识别项目类型并安装依赖 install_deps(dir)?; // 3. 登记到任务清单 register_task(task, branch, dir)?; println!(worktree 已就绪: {}, dir); Ok(()) }run_git是个简单的进程包装用std::process::Command执行 gitfn run_git(args: [str]) - ResultString { let output Command::new(git) .args(args) .output() .context(执行 git 命令失败)?; if !output.status.success() { bail!( git {} 失败: {}, args.join( ), String::from_utf8_lossy(output.stderr).trim() ); } Ok(String::from_utf8_lossy(output.stdout).trim().to_string()) }install_deps的核心是识别项目类型看根目录下有没有package.json、Cargo.toml、requirements.txt、go.mod等特征文件然后执行对应的安装命令。这一步是整个并行流程能跑起来的隐形关键——没有自动装依赖的话每个 worktree 都需要人手动进去敲一遍安装命令10 个任务就有 10 次重复劳动烦躁感直接劝退。register_task用 JSON 文件记录任务元数据{ fix-login-timeout: { branch: cc/fix-login-timeout, dir: ../cc-fix-login-timeout-202506171030, created_at: 2025-06-17T10:30:0008:00, note: } }这份 JSON 保存在仓库根目录的.cc-worktree/tasks.json或用户 home 下的~/.config/cc-worktree/tasks.json。我建议放在仓库外因为放在仓库里会导致每个 worktree 都要处理这个文件的版本冲突反而违背了隔离的初衷。3.4 一个被刻意省略的东西不需要 async runtime这个工具里没有任何tokio也没有async。关于 Rust 的 async 生态很多人都默认Rust 写工具就得用 async这是个误解。异步机制解决的是高并发、多连接场景下的资源复用问题而这个工具执行的是一系列短小、顺序依赖的外部命令先 add再 install再 register每一步的结果决定下一步不存在需要同时处理几十个网络请求的场景。引入 async runtime 的代价是明显的依赖数量翻几倍、编译时间变长、二进制体积变大、代码复杂度上升。用同步的std::process::Command写出来的代码逻辑直接对应人类的心智模型出错也好排查。这一点也是 Rust 的好处——它的std::process::Command很成熟对胶水类工具的支持非常好不需要借助 async 生态就能写出可靠的工具。我见过不少人一上手 Rust 就先装一堆 async 库真到用的时候全是顺序逻辑async 代码里再包一层block_on纯属自找麻烦。判断要不要 async 的标准很简单你的工具是不是要同时处理大量并发 IO是就用不是就老老实实同步。4. 完整实操从零创建 Worktree 到跑通 10 个并行会话4.1 环境准备与工具编译实操之前先列一排环境要求。Git 版本必须在 2.5 以上正常装个新点的 Git 就行。Claude Code 的安装这里不展开网络上资料很多核心点就是装完之后有一个claude命令行工具。Rust 工具链我用标准方式装的rustup装完自带cargo。先把工具编译出来cargo build --release cp target/release/cc-worktree /usr/local/bin/编译产物大小大概不到 1MB我实际看到的大小在 800KB 左右。复制到PATH之后全局每个目录都能调用。4.2 演示连续创建 5 个并行任务我拿一个实际的 Rust Web 项目做演示。假设这个项目当前在main分支上我要并行推进 5 个任务修登录超时、升级数据库连接池配置、优化缓存策略、加一段定时任务、重构错误处理。按传统方式我需要在心里默念五遍git worktree add、又建分支、又装依赖那套流程。现在统统一句话cc-worktree add fix-login-timeout cc-worktree add upgrade-sqlx-pool cc-worktree add tweak-cache cc-worktree add scheduled-job cc-worktree add refactor-error-handling工具自动完成了下面这些事为每个任务创建独立分支cc/task在项目上级目录生成../cc-task-时间戳工作目录检测到这是 Cargo 项目自动在每个 worktree 里执行cargo build将每条任务登记到~/.config/cc-worktree/tasks.json然后我依次进入每个目录启动 Claude Code 会话cd ../cc-fix-login-timeout-202506171030 claude注意你甚至不一定要先cd再启动 Claude Code。业界常用的方式是把cd dir claude作为一条命令但cc-worktree没有做打开会话这一步——原因是我试过用一条命令去嵌套启动者会导致子进程的退出信号处理变得很复杂直接让用户自己执行两步操作反而更干净。工具不必包揽所有事刚好才是最好的设计。4.3 资源占用实测与性能观察10 个 Claude Code 会话同时在跑资源占用是很多人关心的问题。我实测下来单个 CLI 会话进程的内存占用大概在 80MB 到 200MB 之间浮动10 个加起来大约一两个 GB 级别跟你给会话塞的上下文长度有关系。CPU 方面只要你不是同时抛 10 个重任务让 AI 产出一大堆长文件平时都很安静。磁盘开销主要来自每个 worktree 的依赖对 Rust 项目来说每个 worktree 都有一个独立的target目录几个 GB 空间是免不了的。这里有个很容易被忽略的观察点10 个会话的物理隔离远比资源占用重要。我在操作中经常同时给 3 个不同任务的会话发指令它们各自改自己的文件互不感知。这种感觉就像你终于给每个人都分了独立的工位再也不会因为别人桌上堆了东西而找不到自己的东西。4.4 会话收尾合并分支与清理 Worktree任务完成之后收尾动作是一个工具价值的试金石。传统方式的收尾非常繁琐你要手动切回主目录、检查分支差异、合并、删分支、删 worktree 目录还可能要清理 list 里残留的 phantom 记录。我用cc-worktree done一条命令解决cc-worktree done fix-login-timeout它内部的逻辑是这样的读取任务清单找到cc/fix-login-timeout分支和对应目录在main分支上执行git merge cc/fix-login-timeout如果合并成功删除远程分支如果有和本地 worktree清理清单中的记录如果合并有冲突退出并提示需要手动处理如果 10 个 pass 都完成最后 main 分支的历史依然干净清晰。每个任务一条独立的 merge commit谁在什么时候干了什么一目了然。这里还有个小技巧合并前先检查分支是否落后 main 太多。工具会在 done 里加一步检查如果分支基于一个很旧的 main 创建且 main 在这些天里已经推进了很多会建议你先手动 merge main 进去跑一遍测试再合并回来。这个步骤在并行量大时特别重要——任务 A 改了 5 天任务 B 昨天才开B 合并回来的时候可能已经踩在了 A 的旧代码上。5. 连开 10 个会话的踩坑记录与应对方案5.1 依赖重复安装缓存与符号链接最大的坑就是每个 worktree 都有一份独立依赖。前端项目尤甚node_modules几百 MB 到几个 GB每个 worktree 装一份磁盘和安装时间都受不了。我先后试过几种方案最终选择的是依赖符号链接到主工作区。原理很简单只在主工作区安装一份完整依赖其他 worktree 的node_modules用一个符号链接指向主工作区的node_modules。ln -s ../../main-project/node_modules ../cc-fix-login-timeout-*/node_modules但这里有个巨大的隐患符号链接会破坏物理隔离。如果 AI 在某个 worktree 里删除了一个依赖或者改了node_modules里的文件其他 worktree 全会遭殃。所以我的方案有个补充约束符号链接只读AI 不允许改依赖如果需要新增依赖必须回到主工作区装完再同步。安全原则这里我做了保守处理冲突型任务同时改大量重叠代码的任务绝不共享依赖目录独立型任务新增功能、独立模块可以共享。怎么判断冲突型还是独立型看它大概率会碰哪些文件——如果两个任务都主要改同一个模块的源码老实分开装依赖多花点磁盘和时间换的是环境稳定。5.2 分支漂移与 merge 冲突的处理策略10 个分支并行开发merge 冲突几乎是必然的。但有个好消息AI 处理的事情往往比较集中冲突的范围通常可控。我的经验是多任务并行时尽量让任务之间不重叠。比如重构整个认证模块和给用户配置加字段这两个任务大概率都会碰user.rs属于天然冲突型能避则避。如果实在避不开我在派任务时会明确告诉会话你只能改auth/目录下的文件其他目录一律只读改动前先确认路径。这套路径护栏的策略非常有效。Claude Code 在会话里也会看到项目结构你只要明确约束它的活动范围它会遵守。我在 arriving 任务时会在会话指令的第一行写清楚范围然后让cc-worktree在创建任务时自动生成一个CONTEXT.md把目录范围、允许触碰的文件、禁止触碰的目录都写进去Claude Code 会在需要时读取它。merge 冲突本身没什么好怕的做好心理准备就行。真正要避免的是merge 后不验证直接把冲突解决完就完事。每次有冲突务必让最后合并进去的那一方跑一遍测试。工具会在done时检查项目里有没有测试命令要求先跑完再合。5.3 会话跑偏与上下文护栏给 Claude Code 套边界Claude Code 在隔离后的 worktree 里基本不会出现看到别人文件的问题但还有另一个跑偏场景会话在属于自己的 worktree 里依然可能把任务扩展到超出预期的范围。比如你让它修复登录超时它修着修着觉得密码加密方式也太老了顺手给你重构了。这不全是坏事但 10 个任务并行时顺手重构的破坏力非常大。它可能让任务 A 偷偷改了任务 B 要用的公共函数完全不打招呼。我的应对是三层护栏任务指令里明确完成标准告诉 Claude Code 什么叫完成不允许超出完成标准做额外改动。CONTEXT.md里的范围约束固定允许修改的文件列表列表之外的文件不碰。收尾时用git diff检查cc-worktree status会列出每个 worktree 相对于自己分支基础的改动文件清单我扫一眼就知道有没有越界文件。这三层叠下来10 个会话同时开出问题的概率大幅下降。5.4 工具的迭代记录从能用到好用的关键改进工具写的第一版非常粗糙只有 add 和 list已经觉得比裸 git 命令好用了。后来随着使用频率上来迭代了几个关键功能。第一个重要改进是完成前状态检查。done命令会先检查 worktree 里有没有未提交的改动如果有工具会提示还有未提交文件是否丢弃。这个提醒防止了无数次误删快照的事故。第二个改进是任务清单的可见性。我把cc-worktree list的输出做成了类似表格的格式每一行是一个 worktree显示任务名、分支、落后/领先情况、最后活跃时间。一眼扫过去10 个任务里哪些还在推进、哪些已经停滞一周清清楚楚。这个停滞预警的功能很实用它让并行任务的管理从靠脑子记变成了看列表就行。第三个改进是给 Claude Code 提供状态读取入口。我在CONTEXT.md里预留了让 AI 自行查询并联通信息的指令比如如果项目的 worktree 状态有变化运行cc-worktree status获取最新情况。这让 Claude Code 自己也能感知整个广播的布局不会盲目去碰其他 worktree 的文件。迭代过程中我发现一个通用结论工具的价值不在于功能多而在于它把开发者从重复性操作中解放出来的程度。每次新增的改进都来自一次让人烦躁的踩坑经历而不是来自对功能的想象。现在这个工具已经成了我每个项目的标配。开一个新项目第一件事是敲cc-worktree编译安装然后整个开发期间全部围绕 add/list/done 展开。从最初的同时开 10 个 Claude Code 就崩到现在随意并行关键不在于工具本身多巧妙而在于 Worktree 这个底层机制被真正用起来了。按我这几轮实操下来的体会最值钱的一点反而是最初没预料到的当你在每个独立 worktree 里运行 Claude CodeAI 给出的代码质量肉眼可见地提升了——因为它的上下文干净了不会被动吸入一堆杂讯。这比省下几个 GB 磁盘或者省几分钟安装时间要重要得多。如果你也在用 Claude Code 做并行任务强烈建议先把我这套流程抄走再从自己的使用习惯出发去改工具方向一定不会错。