堆叠式评审请求
堆叠式 PR 把一个大改动拆成一串有先后依赖的评审请求，每个都基于前一个分支。好处是评审粒度小、可以逐个合入，避免一个巨型请求长期挂着。代价是要维护分支链条：底部合入之后，上面几层必须重新对齐到新主干位置，否则差异里会混进已经合入的内容。
基本信息
| 结构 | 后一个分支以前一个分支为基础，依次向前 |
|---|---|
| 合并顺序 | 自底向上，下层先合入 |
| 同步方式 | 用变基把上层分支重新落到新主干，可配合引用同步选项 |
| 工具支持 | 引用同步选项可一次更新多条堆叠分支（较新版本 Git） |
典型使用场景
- 大改动按能力拆成若干小请求，逐层评审
- 重构先行、功能随后，拆成两层避免一个请求混杂两类改动
- 底层接口未定稿时，让上层先按假定的接口推进
- 团队希望每个请求都能独立看懂、独立回滚
- 需要较细的评审粒度，但不愿长时间等一次巨型评审
链条维护
链条维护
git switch feature/1
git rebase origin/main # 底部分支对齐主干
git rebase --update-refs origin/main # 同步下游堆叠分支的引用
git branch -vv # 核对各层分支指向的提交
gh pr list --state open # 查看链条上的评审请求状态什么时候做什么
| 时机 | 动作 | 注意事项 |
|---|---|---|
| 底部请求合入 | 上层分支重新变基 | 差异里不应再包含已合入的内容 |
| 底层被要求修改 | 用引用同步选项更新上层 | 逐层核对冲突 |
| 调整提交顺序 | 用交互式变基 | 先确认依赖方向再动手 |
平台不会自动处理顺序：底部请求合入之后，上层请求的分支需要重新指向新主干位置，否则差异会包含已经合入的内容。
链条越长维护成本越高，三层以上时最好配上引用同步选项与统一的分支命名约定，减少手工对齐的次数。