📌 项目地址：max-sixty/worktrunk | ⭐ 7,136 颗星 | 🔧 Rust | 📜 未标注
问题本身很简单：worktree 的命令行设计太糙
现在同时跑 5-10 个 Claude Code 或 Codex 已经不稀奇。每个 agent 给一个独立的 git worktree，是最干净的隔离方式——各改各的目录，互不覆盖。
但 git 原生的 worktree 交互确实难受。README 里的例子：新建一个 worktree，同一个分支名要打三次——
git worktree add -b feat ../repo.feat
cd ../repo.feat
这才只是”开始干活”。清理的时候还得回主目录、remove worktree、删分支，三步。如果手上有十个 worktree，这些琐碎操作的总量很可观。
Worktrunk 的做法：分支名就是地址
核心抽象一句话说完：用分支名寻址 worktree，路径由可配置的模板自动算出来。所有接受分支名的命令，也接受 worktree 的实际路径，两种写法随意。
于是操作对比变成这样：
| 任务 | Worktrunk | 原生 git |
|---|---|---|
| 切换 worktree | wt switch feat |
cd ../repo.feat |
| 创建并启动 Claude | wt switch -c -x claude feat |
git worktree add -b feat ../repo.feat && cd ../repo.feat && claude |
| 清理 | wt remove |
回主目录 + git worktree remove + git branch -d |
| 带状态列表 | wt list |
git worktree list（只有路径） |
wt switch -c -x claude feat 这一条基本浓缩了项目价值：建分支、建 worktree、cd 进去、启动 Claude，一条命令。这个交互模式明显是照着“给 AI agent 派活”设计的——每个新任务一条命令开一个隔离环境。
几个我觉得有用的设计
构建缓存共享。跑十个 worktree 最痛的不是 git 操作，是每个 worktree 里 target/、node_modules/ 都要重新构建。Worktrunk 支持共享这些被 ignore 的目录，十个 worktree 不用重复构建。对 Rust 和 Node 项目来说，这一条省下的时间可能比省下的打字时间多一个数量级。
Hooks。在 create、pre-merge、post-merge 等时机自动执行命令，本地工作流可以固化下来。
合并工作流。squash、rebase、merge、清理合成一条命令，收尾阶段不用来回切目录。
其他还有：从 diff 生成 commit message 的 LLM 集成、带 diff 和 log 实时预览的交互式选择器。配置细节 README 没展开，文档在 worktrunk.dev。
项目状态
2026 年初发布，作者称它已经是用户最多的 git worktree 管理器（7,136 star，这个说法可信度不低）。作者在 README 里明确说在密集收集使用反馈，任何摩擦点都欢迎提 issue——项目处于快速迭代期，功能可能变，但有人修问题。
我的判断：如果你现在用裸 git worktree 管理并行任务，学习成本就三个命令，直接换上试半天就知道值不值。如果只是偶尔开一个 worktree，收益有限，不必为了工具而工具。