Copilot上线堆叠PR 重构老代码不用再切分支

堆叠PR开发场景

一个维护者想给搁置了很久的项目补上拖欠的功能时，通常会卡在同一个地方：改动横跨好几个模块，一次提一个巨型 Pull Request，评审的人看完开头就放弃了；拆成十几个小 PR 挨个合并，又要在分支之间来回切换，改到后面自己都记不清哪个分支包含哪个改动。

这个场景 GitHub 显然见过很多次。Copilot 应用最近上线的"堆叠会话"和"堆叠拉取请求"功能，就是在处理这件事。

一串PR排队合并这就是stack

GitHub 官方的描述很直白：一个 stack 就是同一仓库里的一串 PR，每个 PR 的目标分支是它下面那个 PR 的分支，形成有序的链，最终一起落到 main 分支。

也就是说，你不用等 PR #1 合并完、再基于 main 开 PR #2，而是直接基于 #1 的分支继续改。一个大的功能改造，可以按阶段拆成几个逻辑上独立的 PR，顺序推进，最后整条链一起合进去。

堆叠PR链式结构

对单人维护的项目来说，这个流程顺了很多。原来一次改 30 个文件不敢提，现在拆成 3 个各自可以 review 的 PR，每个 PR 的 diff 都在可控范围内，评审的人不用一次性面对一大坨改动。

链式提交带来的变化，不只是"少切几次分支"。

评审顺序变成了强依赖。链中间的 PR 合并不了，后面的 PR 也跟着动不了，评审的人得按顺序看。合并顺序从"谁先提谁先合"变成了"链的结构说了算"。

CI 也要重新理解。链上每个 PR 的 CI 跑在未合并的父分支上，一个 PR 的测试结果，可能受它下面那个 PR 的改动影响。排查失败时，得先分清是链上哪一环引入的。

代码评审工具也得跟上。链式提交下，只看单个 PR 的 diff 很难判断上下文，评审工具需要支持跨 PR 查看整条链的改动。如果团队用的评审工具没有这个能力，堆叠 PR 用起来会别扭很多。

这些在单人或小团队场景下都不是大问题，反而省事。但多人协作时，不同开发者改到同一段代码，链式依赖的 rebase 成本比独立分支更高。官方没有说明是否支持自动冲突解决，实际使用中这部分大概率还是要人工处理。

堆叠 PR 并不是新概念。Graphite 这类第三方工具做了好几年，很多团队已经在用类似流程管理大型重构。Copilot 应用把它内置，说明这个工作流已经从"少数团队的技巧"变成了平台默认能力。

但内置不等于解决所有问题。链上某个 PR 被改动后，整条链怎么重放、rebase 顺序怎么安排、合并顺序由谁决定，这些在多人仓库里会变得尖锐。目前没有公开信息说明 GitHub 对这部分做了什么处理。

这个功能真正改善的是"一次大改动"的提交流程——把大决策拆成一系列小决策，每个小决策可以独立被 review。对长期维护的老项目，这是实打实的效率提升。至于链式依赖带来的新约束，小团队基本感受不到，大团队则需要先约定好链的合并策略，再决定要不要全面用起来。

维基框架关注企业应用开发中的长期维护问题。在实际项目中，业务系统往往同时涉及权限、微服务、接口协议、部署环境等复杂因素，因此我们希望提供一套更容易扩展和维护的基础框架。