GitHub 推出 Stacked PRs，告别巨型代码审查
Stacked PRs are now live on GitHub
GitHub 正式开启 Stacked pull requests 的公共预览，彻底改变大型代码变更的协作方式。这项功能允许开发者将庞大的改动拆解为一系列有序的小型 pull request，每一层都代表一个专注的变更点。团队可以并行审查每一层，无需再手动 rebase 多个分支，最后只需一键即可合并整个堆栈。Next.js 和 TED 等团队已率先采用，反馈显示这不仅大幅提升了审查效率，还让代码质量更可控。无论是通过 GitHub CLI 扩展、网页端还是 GitHub Copilot，开发者都能轻松创建和管理代码堆栈，让复杂的功能发布变得井井有条。
曾经，一个大改动意味着没人愿意审查的巨型 PR；现在，它变成了一堆审查者能真正看懂的小 PR，整个堆栈还能一次性合并。
HN 评论区
284- matharmin
我用这个预览版有一段时间了，看到它在这么多问题尚未修复的情况下就扩大预览范围，我感到相当惊讶。
举个例子，合并整个 PR 栈在很多情况下完全无法正常工作：https://github.com/github/gh-stack/discussions/212
你可以逐个合并，但如果你使用的是 squash and merge，并且要求代码审查，那么栈中的每个 PR 都需要重新审批。这让你失去了堆叠 PR arguably 最大的优势。
命令行工具（gh stack）确实让操作稍微不那么手动，但你仍然必须非常清楚 git rebase 的工作原理，工具只是帮你跨多个分支自动化这个过程。例如，如果你的本地分支与远程不同步，直接运行 UI 建议的 "gh stack rebase" 命令是行不通的，而且工具也不会提示你这一点。
我觉得这个栈 UI 还不错。相比独立的 PR，它相当简洁，但足以展示它们之间的关系。
（我的所有评论都假设你已经有充分的理由去堆叠 PR。这套工具只是让工作流更容易，并没有带来任何新功能）
- sameenkarim
来自 GitHub Stacked PRs 团队！
很高兴能更广泛地发布此功能，让任何人都可以开始使用堆叠：https://gh.io/stacks
非常希望能听到大家的反馈，尤其是关于 UI 和 CLI 的。我们还有更多 PR 体验的更新即将推出！
同时也乐意回答关于我们设计决策的问题。幕后发生了很多事情，这是 GitHub 历史上规模最大的发布之一，几乎涵盖了从 Actions 和保护规则到 CLI 和移动应用的所有服务。
- steveklabnik
这是 GitHub 多年来最大的变化之一。很高兴看到像这样的功能部署到了全球最大的代码托管平台之一，希望这能让许多开发者接触到他们以前甚至不知道的工作流。
如果你认同堆叠能产出更好的软件，那么这也确实有机会帮助到相当多的人。
- Okkef
这种堆叠 PR 相比精心整理的提交集并按提交逐个审查，有什么优势？
我认为更大的问题是，大型 AI 生成的 PR 需要不同的审查方式。例如，diff 的展示顺序会对提交的易读性产生巨大影响（比如先展示函数定义的变更，然后是所有调用点，最后是测试）。
或者，我们是否应该转向一种 diff 和评论交织在一起的体系，有点像“文学编程”（Literate Programming）将代码与散文交织的方式。
文学化 diff / 文学化 Pull Request……我还没找到类似的东西。
- zelphirkalt
我记得几年前在 Gitlab 上试过这个。一个 PR 依赖另一个，再依赖另一个……最终体验并不好。部分原因是 Gitlab 的界面问题，但也是因为没必要把 PR 搞得更复杂。
- lucky_cloud
这就是为什么菜单切换图标是那个煎饼堆 emoji (U+1F95E) 吗？
这种俏皮感虽然不错，但这个改动让我对我看到的东西超级怀疑。
- chill_ai_guy
这大概晚了好几年。这是为人类还在审查 PR 的时代准备的。无论好坏，那已经成为过去式了。审查环节已经大幅左移，而新一代的 Git 重构（比如 Origin）几乎肯定不会再有 "PR" 的概念，更不用说堆叠它们了。
- shoyer
什么时候能支持带有依赖变更的 PR "树"？根据我在 Google 使用堆叠变更的经验，变更往往不是线性历史。我想象，在如今并行编码代理盛行的情况下，这种情况尤其常见。