多层依赖分支的PR合并顺序是否重要？相关疑问咨询

我有一个main分支，经过若干次提交后基于main创建feature1分支；完成若干次提交后，基于feature1创建feature2分支；接着完成若干次提交后，基于feature2创建feature3分支，分支结构如下：

main
                |
 a -- b -- c -- d
                 \       feature1
                  \          |
                   e -- f -- g 
                              \                       feature2
                               \                         |
                                h -- j -- k -- l -- m -- n
                                                          \    feature3
                                                           \     |
                                                            o -- p

我为这三个分支分别创建了PR，查看feature2的PR时，会显示其与main的全部差异（包含feature1的变更），导致评审困难。以下是两个疑问及解答：

1. 此种场景下PR的合并顺序是否重要？若先合并feature1的PR，此时查看feature2的PR会显示什么？是否需要拉取main并将feature2重基（rebase）后推送更新PR？ #

• 合并顺序非常重要，直接关系到PR的差异清晰度和后续合并的复杂度。
• 先合并feature1到main后，feature2的PR默认仍会展示和main的全量差异（包含已合并的feature1变更）——因为feature2的基准还是合并前的main（d提交），而非合并后的main（g提交）。
• 要让feature2的PR只显示自身相对于main的增量变更，需要拉取最新的main分支，将feature2重基到main上：

  git checkout feature2
  git pull origin main
  git rebase main
  git push -f origin feature2
  

  重基并推送后，PR的差异就只会展示h-j-k-l-m-n这些feature2独有的提交内容，评审难度会大幅降低。

2. 若先合并feature2的PR（feature1和feature3仍处于开放状态），feature1的PR会发生什么？会自动合并吗？若需要手动合并，其变更内容是什么？ #

• feature1的PR不会自动合并。此时feature1的所有变更（e-f-g）已经通过feature2合并到main里了，所以feature1和main的差异会变成空。
• 手动合并的话，不会产生任何新的提交或变更——因为feature1的所有提交都已经存在于main中，合并操作只是把feature1分支标记为已合并状态而已。

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