HN Weekly 中文
← #790

GitHub Stacked PRs：官方原生支持的堆叠式 PR

查看原文 HN 讨论

文章摘要

GitHub Stacked PRs 是 GitHub 官方推出的堆叠式 Pull Request 支持，目前处于私有预览阶段，需加入候补名单使用。它要解决的核心痛点是：”大 PR 难审、慢合、易冲突”——当一个分支积累了太多改动，审查者失去上下文、反馈质量下降，整个团队的节奏也会被拖慢。

所谓”堆叠 PR”是指把一组改动拆成”同一仓库里的一串 PR”，其中每个 PR 的目标分支是前一个 PR 的源分支，形成一条有序链路，最终落到 main。这样每个 PR 都是一个独立、易审阅的小单元，同时彼此又保持逻辑顺序。

GitHub 原生支持带来了若干关键能力：PR 页面内嵌”stack map”可视化，让审查者在链路中的各 PR 间跳转；分支保护规则按最终目标分支（通常是 main）强制执行，而非各自相对的直接父分支；CI 也以”仿佛都针对 main”的方式运行，保证正确性。合并方面，一旦多个 PR 都通过 CI，可以批量合并，余下未合并的层级会自动 rebase。

配套的 gh stack CLI 简化了本地操作：新建层级分支、自动 rebase、批量推送、生成 PR，均为可选使用——原生工作流在 Web 端也能完成。对 AI 编码智能体，GitHub 还提供 npx skills add github/gh-stack 集成，使代理原生理解堆叠式工作流。整体来看，这是把此前 Graphite、Phabricator、Meta 的 arc 等外部工具提供的堆叠式体验，正式内建到 GitHub 平台的一次关键演进。

HN 评论精华

  1. 堆叠 diff 是工作流升级：adamwk 明确表达对 stacked diffs 的推崇，认为它让”长周期功能开发的审查与协作都舒服很多”。小 PR 意味着可以边实现边拿反馈，而不是积压成一大坨再交付；这种节奏明显优于传统”写完一大包再开 PR”的方式。

  2. 企业规模下 Git 已不够用：steveklabnik 从更大的视角回顾——Meta、Google 等巨头之所以自建版本控制系统（如 Sapling、Piper），正是因为 Git 无法胜任超大 monorepo。堆叠式 PR 反映了”性能不止是 CLI 速度”的事实；他同时提到 jujutsu 这类新一代 VCS 能在本地就提供类似体验。

  3. 逐 commit 审查 vs squash-merge：adityaathalye 对 GitHub/GitLab 的审查模式颇有微词，更偏爱 Gerrit 风格：保留每个 commit 的独立历史、逐 commit 评审、不丢失演化过程。他认为不可变的变更历史对安全追溯、团队教学和回滚都更有利，squash-and-merge 则抹掉了太多信息。

  4. Git 本身的局限：forrestthewoods 质疑 Git 根本就不适合大型项目——全量历史存储代价高、二进制文件处理糟糕、即便有 LFS 也不够。他举例大型游戏/影视工作室普遍选择 Perforce，而不是 Git+LFS，Stacked PRs 解决的也只是表面问题。

  5. Mercurial/Sapling 的架构优势：ezst 指出 Mercurial 在设计层面把分支信息作为 commit 元数据永久保留，这是 Git 所没有的。Facebook 投入基于 Mercurial 的 Sapling，就是看中其数据模型更优——即便 Python 实现慢，换来的结构优势让 stacked workflow 和大规模协作都更自然。