解决合并冲突后PR未自动标记合并的原因探究

背景回顾 #

分支创建路径：Main → release/2024-12-12 → feature/NewMenu
向develop提交feature/NewMenu的PR时，因其他分支已合并到develop导致冲突，两种操作流程产生不同结果：

第一种操作（不符合预期） #

1. git branch  # 当前分支为feature/NewMenu
2. git pull
3. git checkout develop
4. git pull
5. git merge feature/NewMenu  # 出现合并冲突，已手动解决
6. git checkout -b mergefix/Resolved
7. git add . && git commit  # 提交冲突解决
8. git push

合并mergefix/Resolved到develop后，原PR未被标记为远程合并。

第二种操作（符合预期） #

1. git branch  # 当前分支为feature/NewMenu
2. git pull
3. git checkout develop
4. git pull
5. git merge feature/NewMenu  # 出现合并冲突，已手动解决
6. git add . && git commit  # 先提交冲突解决
7. git checkout -b mergefix/Resolved
8. git push

合并mergefix/Resolved到develop后，原PR被正确标记为合并。

两种操作的核心差异 #

1. 冲突解决的提交分支不同

   • 第一种操作：在新建的mergefix/Resolved分支上提交冲突解决，此时本地develop分支仍处于「合并冲突未完成」的状态，feature/NewMenu的变更从未被正式合并到本地develop的提交历史中。
   • 第二种操作：先在本地develop分支上完成冲突解决的提交，这个提交会把feature/NewMenu的所有变更和冲突修复内容整合进develop的本地提交历史，再基于这个完成合并的分支创建mergefix/Resolved。

2. 远程develop的提交历史关联不同

   • 第一种操作：合并mergefix/Resolved到远程develop后，远程develop的提交历史里只有冲突修复的内容，但完全没有包含feature/NewMenu分支的原始提交。PR平台检测不到目标分支包含源分支的变更，所以不会标记PR为合并。
   • 第二种操作：mergefix/Resolved继承了本地develop已完成合并的提交历史，合并到远程develop后，远程分支的提交历史明确包含了feature/NewMenu的所有变更。PR平台能识别到源分支的变更已被整合进目标分支，因此自动标记PR为合并。

本质原因 #

PR平台判定合并的核心逻辑是：目标分支的提交历史是否包含源分支的所有提交。第一种操作相当于绕开了feature/NewMenu直接向develop提交了修复内容，没有建立两者的关联；第二种操作则先在本地完成了feature/NewMenu到develop的合并，再通过新分支同步到远程，让PR平台能识别到源分支的变更已被纳入目标分支。

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