子Pull Request自动合并至Master分支的原因及规避方案咨询

原因分析 #

GitHub判断一个Pull Request是否已合并，核心依据是该PR的所有提交是否已经存在于目标分支的提交历史中，而非是否手动执行了"合并"操作。

在你的场景里：

• PR2基于PR1的分支创建，因此PR2的提交历史包含PR1的所有变更；PR3基于PR2创建，同理包含PR1、PR2的全部提交。
• 当PR3合并到release分支后，release分支的提交历史已经包含了PR1、PR2的所有提交。
• 把release分支合并到master后，master分支自然继承了这些提交，GitHub检测到PR1、PR2的所有提交都已存在于master，就会自动将这两个PR标记为"已合并"。

你觉得PR1、PR2会被PR3"取代"，但实际上GitHub的PR状态只看提交是否落地，不区分提交是通过哪个PR合并进来的。

规避方法与最佳实践 #

1. 合并上层PR时使用压缩合并，手动关闭前置PR #

当合并PR3到release分支时，选择Squash and merge（压缩合并）或Rebase and merge（变基合并）：

• Squash and merge会把PR3分支的所有提交（包括PR1、PR2的）压缩成一个全新的提交，这样release分支的历史里不会保留PR1、PR2的原始提交记录。
• 合并完成后，手动关闭PR1、PR2，在关闭说明里标注"变更已包含在PR3中，无需单独合并"。后续将release合并到master时，GitHub不会检测到PR1、PR2的原始提交，也就不会自动标记它们为已合并。

2. 用独立分支构建链式PR，避免分支嵌套 #

不要让PR2基于PR1的分支、PR3基于PR2的分支，而是：

• 从release分支切出PR1的工作分支，完成开发后提交PR1。
• 从release分支切出PR2的工作分支，将PR1的变更通过git cherry-pick复制到PR2分支，再添加PR2的新变更。
• PR3同理，从release分支切出，复制PR1、PR2的变更后添加新内容。
  这样每个PR的分支都直接基于目标分支（release），相互独立。当PR3合并后，PR1、PR2的分支不会被影响，它们的提交也不会进入release分支，自然不会在合并release到master时被误标记。

3. 调整分支策略，采用"中间集成分支" #

放弃直接在release分支上做链式PR，改用更规范的分支策略：

• 所有功能PR（PR1、PR2、PR3）先合并到develop分支，完成集成测试。
• 确认稳定后，将develop合并到release分支做预发布验证。
• 最后将release合并到master发布。
  链式PR仅在develop分支上进行，release只接收最终的集成结果，能避免前置PR的提交被带入master分支导致误标记。

4. 事后补救：修正PR状态 #

如果已经出现了PR1、PR2被自动标记为已合并的情况：

• 重新打开PR1、PR2，然后立即关闭，并在关闭说明里明确标注："本PR未单独合并，其变更已包含在PR3中，合并release到master时被自动标记为已合并"，避免其他团队成员误解。

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