为何GitHub拉取请求解决冲突时会生成两次合并提交？

这个问题其实是GitHub Web端冲突解决工具的工作机制导致的，我来给你拆解清楚：

背后的原因 #

你创建的PR是base=feature、head=master，目的是把master上的提交A同步到feature。当GitHub检测到冲突并让你在UI里解决时，它的处理逻辑是这样的：

1. 首先，它会在**head分支（也就是master）**上执行一次合并操作：把feature分支合并到master，生成提交D（提交说明就是Merge branch 'feature' into master）。这一步是为了在master的代码上下文里解决冲突，确保解决后的代码能在master分支上正常运行。
2. 接着，GitHub会把这个已经解决完冲突的master分支，合并到你的目标分支feature，生成提交C（也就是PR的正式合并提交Merge pull request #xyz from master）。

这就导致master和feature分支都包含了对方的所有变更，看起来两个分支等效，但master多了一个额外的合并提交D——这显然不是你想要的结果，因为你只需要把master的变更同步到feature，不想改动master分支。

如何避免这个问题？ #

如果你只想把master的变更同步到feature，同时不污染master分支，推荐这几种方法：

1. 本地解决冲突后合并（最直观）

放弃用GitHub Web UI解决，转到本地操作：

# 切换到feature分支
git checkout feature
# 拉取master的最新变更
git pull origin master
# 此时会提示冲突，手动解决冲突文件
# 解决后提交合并
git add .
git commit -m "Merge master into feature (resolved conflicts)"
# 推送到远程feature分支
git push origin feature

这样只会在feature分支上生成一个合并提交，master分支完全不会被修改，完美符合你的需求。

2. 用Rebase代替合并（更干净的历史）

如果你希望feature分支的提交历史更线性，不想保留合并提交，可以用rebase：

git checkout feature
# 基于master的最新提交重放feature的变更
git rebase master
# 解决冲突后继续rebase
git rebase --continue
# 推送到远程（因为rebase修改了历史，需要强制推送，确保没人在feature上工作）
git push origin feature --force-with-lease

这样feature分支会直接基于master的提交A，没有多余的合并提交，历史更整洁。

3. 调整PR的操作逻辑

其实你想要的是让feature分支追上master的变更，这种场景下更合理的操作是在feature分支上主动合并master，而不是创建一个从master到feature的PR。因为PR通常用于把开发分支的代码合并到主分支，而主分支同步到开发分支，本地操作会更灵活且不会产生意外提交。

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