波仔
🧡 第八章 多智能体协作
📄 一句话概括

并行最大的技术障碍是两个任务改同一个仓库会打架；worktree 是标准解法，它把打架推迟到你愿意处理的时候。

📝 本节和前面几节的关系

上一节说并行划不划算，这一节解决并行时的第一个技术麻烦。

一、先说清那个麻烦

两个任务都要改同一个仓库的同一批文件时，它们会互相踩。 更糟的是：你没法同时开两个窗口干活，因为工作目录只有一份。 有人会说那我手动切换——切换来切换去，上下文全丢了。

二、worktree 做了什么

它让同一个仓库同时有多份独立的目录，各有各的分支。 你在 wt-a 里改登录页、在 wt-b 里改文案，两边互不干扰。 需要合并时才碰面——而且冲突当场就能看见，不用等到最后一天。

三、本节的演示是真跑了一遍

建仓库 → 建两个 worktree → 各自改 → 各自提交，主分支纹丝不动。 输出里那三行内容就是证据：主分支还是第一版，两条分支各改各的。 所以它的价值可以一句话说完：把打架推迟到你愿意处理的时候。

四、什么时候值得用

两件事要改同一个仓库，而且两件事都不小。 反例：两件事改的是毫不相干的目录——那用两个普通目录克隆就够了，不必上 worktree。 上 worktree 之前先问一句：它们会不会碰到同一批文件？会，才用。

五、动手 Demo：worktree——并行运行的基础设施

下面在一个临时仓库里真跑一遍：建两个工作区，各自改、各自提交。

git("worktree", "add", "-q", "-b", u"feat-a", wt_a)
git("worktree", "add", "-q", "-b", u"feat-b", wt_b)
# 各改各的、各自提交，主分支不动
git("commit", "-q", "-m", u"A 的改动", cwd=wt_a)
git("commit", "-q", "-m", u"B 的改动", cwd=wt_b)

实跑输出：

--------------------------------------------------------------------
worktree——并行运行的基础设施
--------------------------------------------------------------------

并行最大的技术障碍是【两个任务改同一个仓库会打架】。worktree 是标准解法。

建好两个并行工作区：
    wt_a  分支 feat-a
    wt_b  分支 feat-b

两个工作区各自改、各自提交，主分支纹丝不动：
    主分支：主分支第一版
    feat-a：A 改的内容
    feat-b：B 改的内容

合并时才碰面——而且**有冲突当场就能看见**，不用等到最后。
这就是 worktree 的全部价值：**把打架推迟到你愿意处理的时候。**

输出里那三行是证据：主分支还是第一版，两条分支各改各的。 worktree 的全部价值就是那句：把打架推迟到你愿意处理的时候。

30 秒实验

  1. 在你常用仓库里试一次：建一个 worktree，在里面改点无关的东西。
  2. 想一想你手上的活：哪两件会碰到同一批文件？那就是该上 worktree 的地方。

常见误区

  1. 手动切换分支来并行。切换一次上下文就丢一次，等于从头再来。
  2. 什么都上 worktree。改毫不相干目录的两件事，克隆两个目录更省事。
自测三问（点开对答案） 1. 并行的第一个技术麻烦是什么？ —— 两个任务改同一个仓库会互相踩，而且工作目录只有一份。 2. worktree 做了什么？ —— 让同一个仓库同时有多份独立目录，各有各的分支。 3. 什么时候值得上 worktree？ —— 两件事都要改同一个仓库、而且都不小；否则克隆两个目录就够。

相关笔记