放心 push to main

“先开 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 各自解决不同的问题：

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 流程。