GitHub把“堆叠式PR”做成原生功能：大改动终于不用再靠勇气提交了
GitHub 终于承认：超大 PR 真的不该再靠人类硬扛
每个写过团队代码的人，大概都见过那种让人血压升高的 PR：改了 3000 多行，标题叫“refactor + fix + cleanup + small improvements”，评论区沉默得像深夜地铁站，审查者点进去三分钟后默默关掉页面，心里只剩一句——“这玩意儿谁来 review？”
GitHub 这次发布的原生 Stacked PRs，瞄准的就是这个老大难问题。它允许开发者把一个大的改动拆成一串有顺序的 pull request：底层先改认证，再往上叠 API，最上面再接前端。每一层都可以单独 review，但它们又彼此相连，最后还可以一键整体合并。配套推出的 gh stack CLI，则负责本地分支管理、级联 rebase、推送和创建 PR 等操作。
这件事看上去只是 GitHub 新增了一个“更聪明的 PR 视图”，但我更愿意把它理解为：GitHub 终于把一种在高效工程团队里已经流行多年的协作方式，变成了官方基础设施。过去，Stacked PR 并不是新概念。Meta、Graphite、Sapling 等生态里，类似工作流早就存在，很多资深工程师也早已靠手工维护“PR 套娃”活了很多年。只是这套方式此前更像高手心法，而不是平台默认支持的公共道路。
从“一个大包裹”变成“分层快递”：为什么它重要
软件开发里，真正拖慢团队的，往往不是写代码，而是“让别人看懂你写了什么”。一个庞大的 PR 最大的问题并不只是文件太多，而是上下文被揉成一团。审查者得同时理解架构调整、接口变更、测试修复和 UI 细节，最后不是漏看，就是只能给出非常表面的反馈。代码评审本来应该是质量控制环节，结果常常被大 diff 逼成了“走流程”。
Stacked PR 的价值在于，它把一个复杂问题重新切成了人脑能消化的尺寸。比如一个新功能涉及数据库模型、后端接口、权限系统和前端展示，过去可能会被塞进同一个 PR；现在可以拆成四层。审查数据库模型的人，不用顺带去看 CSS；看前端的人，也能明确知道依赖的是哪一层。反馈会更具体，冲突范围也更小，合并节奏自然更顺。
GitHub 在这次功能设计里做对了一点：它不是只让开发者“能这么干”，而是让平台“理解这件事”。PR 界面会显示 stack map，方便 reviewer 在层与层之间跳转；CI 会把每个 PR 都按最终目标分支来跑，避免“局部通过、整体翻车”；分支保护规则也是看最终落点，而不是只看当前直接 base branch。这些细节其实比“一键合并”更关键，因为它们决定了 Stacked PR 不是一个技巧，而是一条可靠的工程路径。
GitHub 不是发明者，但它可能是普及者
如果你关注过开发者工具，这次发布其实有点“虽迟但到”的意味。过去几年，围绕 Stacked Diff/Stacked PR 已经形成了一波小而强的产品机会。最有代表性的就是 Graphite，它几乎就是围绕 GitHub 上的 stacked workflow 做产品；Meta 则长期在内部推动 stacked diffs 文化，Phabricator 年代就已经把“把大改动拆开 review”当成基本素养。换句话说，市场早就证明：这是开发协作中的真需求，不是什么小众癖好。
GitHub 现在亲自下场，意义非常直接：原来需要第三方工具、额外培训、团队纪律才能运转的工作流，开始有了平台级默认支持。对大团队来说，这会降低推广成本；对中小团队来说，这甚至可能是他们第一次真正接触 stacked workflow。毕竟很多团队不是不知道大 PR 有害，而是嫌麻烦——拆分、建分支、改 base、rebase、处理依赖关系，这一套手工活足够把人劝退。gh stack 的价值，说白了就是把这些原本容易出错、也非常烦人的机械劳动自动化。
但平台亲自做，也意味着竞争格局会变。那些依赖“GitHub 原生能力不够”而成长起来的工具，接下来会被迫往更深层的团队管理、review 分析、工作流洞察走。基础设施一旦被 GitHub 收走，生态产品就得证明自己不只是“补丁”，而是真有额外价值。
AI 编程时代，为什么 Stacked PR 反而更关键了
这次发布里有个容易被忽略、但很有时代感的细节：GitHub 还提到可以通过 npx skills add github/gh-stack，教 AI coding agents 学会处理 stack。这个动作很微妙，它透露出一个现实——未来不仅人类开发者在提交代码，AI 代理也会越来越频繁地制造变更。
而 AI 最大的风险之一，恰恰就是“很能写，但容易一口气写太多”。任何用过代码生成工具的人都知道，AI 特别擅长瞬间甩给你一个看起来完整、实际上混杂多层逻辑的大 diff。它可能同时动数据库、API、测试和前端，再顺手“优化”一堆无关代码。这样的提交对于审查者来说并不比手写巨型 PR 更友好，甚至更糟，因为你还得额外怀疑它有没有在某个角落偷偷埋雷。
从这个角度看，Stacked PR 不只是人类协作优化，也是在给 AI 时代的代码治理提前铺路。未来好的 AI 编码系统，不应该只是会写代码，而应该懂得把变更组织成适合团队审查和上线的形状。如果 GitHub 这套 stack 工作流能被 AI 工具广泛采用，我们看到的可能不是“AI 一次生成 5000 行代码”，而是“AI 帮你生成 5 个各自清晰、可逐层验证的 PR”。这是两种完全不同的开发文明。
真正的考验，不在功能上线，而在团队愿不愿意改习惯
当然，工具到位不代表文化自动升级。Stacked PR 最大的门槛，从来不只是命令行有多复杂，而是团队是否愿意重新思考“什么叫一个好的提交”。很多工程团队已经习惯了 feature branch 一把梭：功能做完，再开 PR，review 只是收尾动作。要切换到 stacked 方式，就得在开发一开始就有更强的结构意识，知道哪些层可以独立审、哪些变更应该先落地。这会对开发者提出更高要求，也会暴露团队架构是否真的足够模块化。
另外，Stacked PR 也不是银弹。它非常适合那些可以自然分层的改动，但对于高度耦合、边改边探索的问题，强行拆 stack 也可能制造额外心智负担。再比如产品节奏紧张时，团队未必愿意维护一长串层级关系；新手开发者如果还没学会干净提交，堆叠起来反而可能把混乱“分装”成好几层。GitHub 解决的是工具问题，但工作流能否真正提升效率，最后还是取决于团队纪律和工程审美。
我自己对这件事的判断是偏乐观的。因为哪怕只有一部分团队开始用原生 stack，把“把大改动拆小”变成一种更自然的默认行为，也已经足够有价值。代码评审这件事，过去太依赖每个开发者的自觉和 reviewer 的耐心了。现在 GitHub 至少给了大家一个明确的信号：大 PR 不再是成熟团队必须忍受的宿命。
如果说过去十年，GitHub 主要定义了代码托管和社交协作的外壳；那么这次 Stacked PRs 更像是在深入软件工程流程的内脏部分。它不是最耀眼的发布，却可能是最贴近开发者日常痛点的一次更新。毕竟，真正让团队效率崩掉的，从来不是“不会写代码”，而是“代码写完以后，谁都不想看”。