Stacked PR 现已在 GitHub 上线

原文 ↗ Hacker News 讨论 ↗

GitHub 新推出的 stacked pull requests 功能现已进入公开预览，旨在帮助开发者将大型代码变更拆分成一系列更小、彼此依赖的 PR，从而更容易审查和合并。许多工程师欢迎对这一工作流的原生支持，因为他们此前只能借助第三方工具或手动分支来模拟，并指出它在 CI、审查范围和并行工作方面都有好处。也有人认为这项功能不完整、有 bug，或与结构良好的 commits 重复；还有人批评 GitHub 忽视了 Gerrit 和 Phabricator 等系统中的先例，或者是在改善核心审查工具之前又增加了一层复杂性。

总体反响

  • 许多人感到兴奋；有评论称 stacked PR 是 GitHub 多年来最大的变化之一，也是相较于其他系统长期缺失的功能。
  • 也有人不以为然，认为这不过是在他们早已使用的模式（PR 指向其他 PR 分支）之上的“UI 糖衣”。
  • 还有人觉得它来得太晚，而且作为 v1 太基础/太有 bug；也有人只是庆幸这次不是另一个 AI 功能。

感知到的工作流收益

  • 可以把大型功能拆分成更小、可审查的单元，同时继续推进后续部分的工作。
  • 支持并行审查：重构 → 后端 → 前端，不同层由不同审查者负责。
  • 支持合并功能栈中的部分子集（例如基础设施 + API，但不合并 UI），并且可以按单元运行 CI。
  • 栈管理（自动 rebase 依赖的 PR、merge-one 或 merge-all）被认为相比手动 rebase 是很大的提升。

批评与局限

  • 有人认为 stacked PR 只是组织或审查问题的权宜之计；他们主张应改进 commit 规范并使用更小、彼此独立的 PR。
  • 也有人担心 stacking 会增加复杂度，鼓励长期存在的分支，并给审查者带来压力（“修改一个 5 层深栈的底部很痛苦”）。
  • 当前实现存在 bug，尤其是在对栈进行 squash merge 以及与 merge queue 交互时；跨仓库和完整 fork 支持仍然缺失。
  • 还有几个人表示，这并没有解决真正困难的部分：把混乱的本地工作重新排序成连贯的系列、真正的跨仓库栈，或依赖变更的树/图结构。

审查与 UI 方面的担忧

  • GitHub 的审查单位仍然是 PR；逐个 commit 审查很别扭，而评论也无法很好地映射到不断演变的 commits。
  • 有人希望 GitHub 采用 diff/patch series 模型，带有 change ID 和 interdiff，就像 Gerrit/Phabricator 以及一些大型内部代码托管平台那样。
  • 栈的网页 UI 被认为非常简陋；重度用户预计仍会依赖 CLI 或自定义工具。

AI 与更广泛的背景

  • 多条评论将 stacked PR 与日益增大的 AI 生成 diff 以及 agent 工作流联系起来，认为它有助于把审查维持在人类可承受的规模。
  • 也有人强调，stacked 工作流早在 AI 出现之前就存在；这项功能主要是在将一种既有实践主流化。