很早之前就写过一篇关于 worktree 的 vibe coding 文章,我想可以再提一下。
大家肯定是因为希望并行地开发功能和修复才使用的 worktree。宝玉老师说可以在同一目录直接并行,这对于相对简单的情况是完全可以的。但是涉及稍微复杂的情况,这样反而丧失了并行带来的好处,不断破坏 Agent 的上下文。这就好似双向同步一样的灾难,Agent A 读取到了文件改动,再顺着改动重读一遍所有的调用,浪费更多的 token,之前的设计决策可能也会被一并推翻。何况 Agent 是有大概率出现细节遗漏,导致仓库同时存在不同的假设。墨菲定律告诉我们这一定会发生。
除了磁盘浪费多份之外,worktree 烦人的另外一点是一个分支只能被 checkout 绑定在一个目录。因为环境变量,端口,我相信很多人的习惯是在主目录进行测试。
所以我觉得最好的一种使用 worktree 的方案是结合 GitHub 或者其他 host,本地 clone 两份 git。测试用一份,开发用一份。worktree 只在开发 git 使用,测试通过 checkout 挨个分支进行测试和收尾。通过之后开发的对话连同 worktree 就可以一并 archive 回收掉。在 Lody 中可以无感地做到这些,archive 了对话,worktree 也就被自动回收。通过 PR 状态感知验收状态。
这样的好处是
- Agent 做的改动永远有留痕和备份,冲突是通过 merge 完整地解决,而不是边做边解冲突。
- 磁盘占用不会无限膨胀,而只和你的最大并发能力有关。
- 脑袋不需要有 worktree 的概念包袱,一个 git 命令不会也可以随便并行,只需要了解干完活把对话 archive 就行。也不用受 branch 已经 checkout 到 abc 目录的折磨。
显示更多
我是能不用worktree就不用worktree,要么不同任务用branch分支,要么就直接同一个分支多任务,一般不太用担心冲突,首先只要任务类型不一样冲突可能性较小。
另外现在 Harness 比如说 Claude Code、Codex 都很聪明,遇到冲突会等另一个执行完。
使用 worktree 主要是在做耗时较长的 PoC 场景,只是验证一下,同时要做其他任务,完了就删除目录。
显示更多