GitHub stacked PR GA：小 diff 不等于独立部署单元

把大改动拆成三个 PR，阅读会更轻松。但上层依赖下层时，短 diff 并不意味着可以单独部署。

10月6日的发布

GitHub 于2026年10月6日宣布正式可用。小 PR 可分别审查并一起合并，支持 github.com 全部套餐。

堆叠以一个 merge group 进入 merge queue；merge commit 方式则为每个 PR 创建 commit。测试组合与历史单元并不相同。

例如 A 添加公共函数，B 在 API 调用，C 实现 UI。各 PR 写明依赖及比较 base。这是流程建议，不是产品自动保证。

只读 B 可能漏掉 A 缺失的权限检查。将 diff 审查与 A+B+C 集成验证分开，并指定最终组合负责人。

GitHub 表示 base 前进后，对除此之外未改动的堆叠 rebase 会保留批准，包括会撤销旧批准的仓库。批准标记与当前集成结果是不同证据。

记录前后 SHA 和测试的 merge group。确认测试是否重跑、日志覆盖哪个组合；单个绿勾不足以作为发布依据。

函数和 API 必须一起上线时，要在部署计划保留依赖。每 PR 一个 commit 并不保证单独 rollback 对剩余调用方安全。

独立修复无需强行堆叠。捆绑可能让所有工作等待一个延迟测试，应评估维护成本。

GitHub 说 auto-merge 将在未来几周逐步推出。先看仓库当前控件，不要假设所有账户今天都有同一按钮。

preview 反馈推动了导航和自动化改进。这表明关注度，不保证团队生产力。请测量自己的审查等待和集成失败。

选择函数与调用方等两个依赖明确的 PR。注明 base、依赖和测试命令，约定集成负责人及 rollback 范围。

同时比较审查节省时间与新增故障。维护成本更高时可回到普通 PR。审查和部署更清楚，比 diff 数量更重要。

发布于10月6日，核对于2026年10月8日。采用前确认仓库规则与可用功能。