开发大型Pull Request时管理依赖的GitHub子PR

我计划给某个开源项目提交PR，核心内容是新增一批独立于主项目的CMake文件，用来辅助构建项目变体；同时还要修改主源码，移除不必要的遗留代码——这类整理性变更有通用价值，我希望能单独提交PR，不跟核心变更混在一起。

因为不是项目维护者，我打算先fork主仓库，然后分PR提交：核心变更作为草稿PR，整理性变更拆成可单独合并的子PR。但不确定维护者会不会在看到完整核心成果前合并子PR，也不想这些子PR被长期分支的大量提交淹没。

我的分支规划如下：

Master -> A -> B -> C -> D
|
|-> Monolithic-Branch -> E -> F -> G -> H -> Rebase Master -> Submit as final
|
|-> SubBranchA -> Cherry E
|
|-> SubBranchB -> Cherry F & G

具体来说，我会先往Monolithic-Branch提交代码，一旦发现有独立价值的变更，就从master分支拉新分支，用cherry-pick提取对应提交并创建子PR。现在有两个疑问：

1. 维护者合并任意子PR和/或整体PR时会发生什么？
2. 在整体PR最终提交前，若部分/全部子PR已合并，从master分支rebase本地分支会产生什么影响？

1. 维护者合并子PR/整体PR时的情况 #

合并子PR的情况 #

• 当维护者合并SubBranchA（提交E）到master后，master分支会新增对应提交（注意：如果用默认合并方式，新提交哈希值会和你cherry-pick出的E不同；若用git merge --ff-only快进合并，则哈希值一致）。
• 合并SubBranchB（提交F、G）时同理，master会新增F、G对应的合并提交或快进提交。

合并整体PR的情况 #

• 若子PR未合并：master会包含E、F、G、H全部提交，后续子PR会被识别为已包含相同变更，维护者可直接关闭子PR，无需重复合并。
• 若子PR已合并一部分（比如E已合并）：Git会自动识别E的变更已存在，仅合并F、G、H的变更（无冲突情况下）。

同时合并子PR和整体PR的情况 #

Git会自动去重相同变更内容，不会产生重复提交；若合并顺序导致冲突，维护者需手动解决冲突后完成合并。

2. 子PR合并后rebase本地分支的影响 #

部分子PR已合并（比如E已合并到master） #

在Monolithic-Branch执行git rebase master时：

• Git会检测到提交E的变更已存在于master，自动跳过该提交，不会在rebase后的分支中重复生成E。
• 剩余的F、G、H会依次应用到最新master分支上，无冲突则rebase顺利完成；有冲突则需手动解决后继续。

全部子PR已合并（E、F、G都合并到master） #

执行git rebase master时：

• Git会自动跳过E、F、G三个提交，仅将H提交应用到最新master分支。此时Monolithic-Branch仅保留核心CMake变更（提交H），后续可直接基于该分支提交最终核心PR。

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