为何GitHub冲突PR解决后会双向合并？如何实现单向合并需求？

问题现象 #

合并Pull Request（PR）时出现两种不同的行为：

• 无冲突场景：仅将PR的源分支（如feature1）变更合并到目标分支（如main），目标分支的新内容不会反向同步到源分支
• 冲突场景：解决冲突完成PR合并后，目标分支的所有变更（如新增文件）会同步到源分支，最终两个分支内容完全一致

复现步骤 #

冲突PR场景 #

• main分支存在文件a.txt，仅包含一行文本
• 从main分支创建feature1分支，修改a.txt中的该行文本
• 在main分支修改a.txt的同一行文本，并新增文件b.txt
• 提交feature1到main的PR，页面显示冲突
• 解决冲突并合并PR后，发现main分支的b.txt被同步到feature1分支

无冲突PR场景 #

• 在feature1分支再次修改a.txt的文本内容
• main分支未修改a.txt，但新增文件c.txt
• 提交feature1到main的PR，页面显示无冲突
• 合并PR后，main分支的c.txt未同步到feature1分支

原因解析 #

这一差异源于GitHub处理冲突合并的特殊逻辑：

1. 无冲突合并逻辑：无冲突时，GitHub默认采用fast-forward或普通合并提交策略，本质是将源分支的提交直接追加到目标分支上，源分支本身不会产生新的提交记录，因此目标分支的新内容不会反向同步到源分支。
2. 冲突合并逻辑：当PR存在冲突，你在GitHub网页端解决冲突时，平台会在后台生成一个新的合并提交——这个提交的父节点同时是源分支和目标分支的最新提交。为了保持PR分支与合并结果的一致性，GitHub会自动将这个合并提交同步回你的源分支（即feature1），相当于你在本地执行了git merge main并推送到远程源分支，这就导致目标分支的变更（如b.txt）进入了源分支。

避免反向同步的解决方案 #

如果只想将源分支的变更合并到目标分支，不想让目标分支的内容反向同步，建议在本地解决冲突后再推送：

• 本地切换到源分支（如feature1），执行git pull origin main拉取目标分支最新内容
• 在本地手动解决文件冲突，提交冲突解决的变更
• 将本地修改推送到远程源分支，此时PR的冲突标记会消失
• 合并PR后，仅源分支的变更会同步到目标分支，目标分支的内容不会反向进入源分支

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