Agent 时代，branch 不再是默认选项

Branch 之所以成为开发默认动作，有它成立时的条件。它既给一条提交历史命名，也逐渐承担代码隔离、并行开发和等待审查等职责。工具和团队规范围绕这些职责生长久了，“先开 branch”便很少再被追问。

Coding Agent 改变了其中一个条件。当每项任务已经在独立远程环境中开发和验证，branch 无需继续负责执行隔离。对于改动小、检查可靠、提交容易撤回，而且没有强制审批要求的 Agent 工作，代码可以直接进入 main。

这个结论有明确范围。大型迁移、外部贡献、多人长期协作，以及受合规或强制 review 约束的仓库，仍然需要 branch 和 PR。需要改变的是低风险 Agent 任务的默认值。

Branch 曾经同时承担隔离和治理

Git 中的 branch 是一个随提交向前移动的指针，本身不会复制代码或创建工作目录。开发者在一个目录里用 checkout 切换版本；需要同时处理多个版本时，可以用 worktree 增加工作目录。

同一个 Git 仓库

repo/          main 的工作目录
feature-a/     feature-a 的 worktree
bugfix-b/      bugfix-b 的 worktree

PR 工作流又把审查、自动检查和审批记录放在 branch 之上。于是 branch 同时代表一条开发线、一个独立工作目录的依据，以及一组等待合入 main 的改动。这些职责相关，却并不相同。

Coding Agent 出现以后，人们自然沿用“一个 Agent、一条 branch、一个 worktree”的组合。它能够隔开文件版本，进程却仍在同一台机器上争用 CPU、内存和端口，依赖、浏览器与后台服务也要由人协调。

Amp 在 2026 年 6 月发布的 Orb 是独立远程执行环境。每个 Orb thread 都有自己的代码副本、依赖、进程、端口和浏览器，Agent 可以在其中开发并完成验证，不会与其他任务争用同一台本地机器。

人仍然可以查看 diff、测试结果和运行环境，必要时进入共享终端或把改动同步到本地。一个任务因此拥有完整的开发与验证现场，无需依靠 branch 和 worktree 获得文件级隔离。

Branch、checkout、worktree、Orb 和 PR 各自解决不同问题。

Branch 表示一条开发线。Checkout 把某个版本展开到当前工作目录。Worktree 新建额外的工作目录，让多个版本同时存在。Orb 提供完整的远程执行环境。PR 负责审查、审批和审计。

Orb 消除的是“为任务准备独立运行空间”这一项旧理由。它不会替代 PR 所承担的治理责任。

多个 agent 可能从同一个 main 开始工作。第一个 agent 提交以后，后完成的 agent 在 push 前 rebase 到最新 main，处理冲突，再重新运行检查即可。

这时 thread 里的上下文还很新鲜。普通冲突可以交给 agent 根据改动意图处理。遇到无法判断的地方，agent 可以直接询问用户，用户也可以补充 prompt 说明取舍。并发带来的冲突仍然存在，解决它已经不需要让 branch 长时间停在那里等待合并。

这套做法成立，需要同时满足四个条件：

审查仍然存在，只是可以在 Orb 中针对 diff 和测试证据完成，无需让 branch 充当等候区。任何一项条件不成立，就继续使用 branch 和 PR。

满足上述条件时，Agent 可以在独立环境里完成开发和验证，rebase 到最新 main，重新运行检查，再直接 push。下一个 Agent 随即从新的 main 开始，改动更早集成，也减少了长期分叉带来的冲突。

团队可以先从文档、测试和局部修复等低风险改动试行，记录冲突率、检查结果与撤回时间。证据表明主线仍然稳定，再扩大范围；只要审查或恢复能力跟不上，就保留现有 branch 流程。