从Fork仓库向父仓库提交PR时如何应用Stacked Pull Requests模式

跨Fork发起PR时平台默认仅支持选择上游父仓库的分支作为合并目标，无法直接指定个人Fork内的功能分支作为PR目标实现原生堆叠，可通过分支管理、标注约定和合并流程配合，达到和单仓库Stacked PR完全一致的小颗粒度评审效果，具体操作如下：

• 本地分支严格按依赖关系维护链式结构，和单仓库Stacked PR的分支逻辑保持一致：
  保持标准分支依赖链：upstream/master -> sideways-fix -> menu-fix -> tabbing-fix，所有改动按功能归属提交到对应分支，上层功能分支统一从最近的已完成前置分支切出，禁止跨分支混放提交。
• 所有分支推送到个人Fork后，发起PR时暂时全部选择上游master作为目标分支，同时做两项标注：
  1. PR标题明确标注堆叠序号与依赖：三个PR标题分别写为[Stack 1/3] fix(Timeline): 修复横向箭头可聚焦性问题、[Stack 2/3] fix(Timeline): 修复菜单按钮可聚焦性问题（依赖PR1编号）、[Stack 3/3] fix(Timeline): 修复Tab键切换顺序问题（依赖PR2编号）
  2. PR描述区开头明确说明：本PR为堆叠序列的第N个，仅当前置序号PR全部合并后再进行评审合并；若当前PR显示包含其他分支提交，均为未合并的前置依赖内容，无需评审。
• 给评审者提供干净的增量diff入口：
  前置PR未合并时，上层PR默认会带上所有前置分支的改动，此时在PR的文件改动页面，手动将对比基准临时切换为个人Fork内对应的前置分支，即可过滤出当前PR真正需要评审的增量代码，把该筛选后的页面链接附在PR描述中，评审者点击即可直接查看无冗余的改动内容，和单仓库Stacked PR的评审体验一致。
• 按顺序合并时自动收敛diff范围：
  当第一个PR（sideways-fix）被上游合并入master后，第二个PR的diff会自动剔除已经进入master的前置改动，仅保留自身的增量内容，无需额外调整目标分支；如果出现代码冲突，单独在对应分支rebase上游master解决即可。第二个PR合并后，第三个PR会自动完成diff收敛，直到整个序列全部合并完成。

维护提示：如果前置PR根据评审意见做了修改，直接在对应本地分支更新后推送，所有依赖该分支的上层分支，只需执行一次git rebase --onto <更新后的前置分支名> <前置分支修改前的commit哈希>同步基址，推送后上层PR的diff会自动同步更新。

内容的提问来源于stack exchange，提问作者Oleksandr Danylchenko