我可能会开始处理一个开源项目的pull请求。正在添加的大多数代码将独立于项目的其余部分，本质上是CMake文件，以帮助构建主项目的变体。在我最初的工作计划中，我已经确定需要对主要源代码进行一些更改，主要是删除不需要的遗留代码，这将阻碍我的其余工作。由于这些更改在整理项目时很有用，我希望能够独立于整个拉取请求提交它们。
我将分叉主回购，因为我不是维护人员，并创建一个跨回购拉取请求。我预计将为主要更改创建一个PR草案，并准备合并那些整理提交的PR。
在看到其余工作的结果之前，维护人员不会保证会合并子拉请求，但我不希望他们在长期运行的分支的所有其他提交中迷失方向。
我假设我可以将提交添加到我的整体分支中，当我发现一个除其他外有用的更改时，我可以从master创建一个新的分支，挑选必要的提交，然后为该子分支创建一个拉请求。
当维护人员合并任何子PR和/或单体PR时会发生什么？如果在我的单体PR作为最终PR提交之前，当部分/所有子PR已经合并时，我从master重新建立基础，我的本地会发生什么呢？
Master -> A -> B -> C -> D
|
|-> Monolithic-Branch -> E -> F -> G -> H -> Rebase Master -> Submit as final
|
|-> SubBranchA -> Cherry E
|
|-> SubBranchB -> Cherry F & G
当维护人员合并任何子PR和/或单体PR时会发生什么？如果在我的单体PR作为最终PR提交之前，当部分/所有子PR已经合并时，我从master重新建立基础，我的本地会发生什么呢？
当维护人员合并您的子PR时，您需要在更新的master分支上重新设置Monolithinc-Branch的基础。这将消除特性分支中的一些提交(根据更改的性质，可能需要解决一些合并冲突(。
如果您的Monolithic-Branch在子PR之前合并，那么子PR可以被丢弃，因为更改已经包含在功能分支中。
最后，如果你有时间，并且你对替代工作流感兴趣，我建议你看看堆叠的git，我发现它对于管理这种情况(你有一堆依赖提交(非常有用。