疑问：解决PR冲突后GitHub为何将develop分支合并至feature分支？

我来帮你理清楚这个问题——这种情况其实是GitHub处理PR冲突时的常见操作，但确实容易让人困惑，尤其是你原本只想把feature分支的代码合并到develop。

为什么会出现反向合并？ #

当你的feature分支和develop分支存在冲突时，GitHub提供了几种冲突解决途径：

• 如果你选择在GitHub网页上直接解决冲突，平台会自动创建一个合并提交，把develop分支的内容合并到你的feature分支中。这么做的目的是让feature分支与develop同步，确保PR能顺利合并。
• 如果你选择本地解决冲突，但执行了git merge develop而不是git rebase develop，也会在feature分支上生成一条develop的合并记录。

本质上，这是让feature分支跟上develop最新状态的必要步骤，但这种“反向合并”的记录确实会让分支历史看起来不够整洁。

如何避免这种情况？（推荐方案） #

想要保持feature分支的提交历史干净，同时解决冲突，更推荐用**rebase（变基）**的方式同步develop分支：

1. 切换到你的feature分支：

   git checkout feature/123
   

2. 拉取远程develop分支的最新代码：

   git fetch origin develop
   

3. 基于最新的develop分支进行变基：

   git rebase origin/develop
   

4. 此时Git会提示冲突文件，打开这些文件解决冲突后，执行：

   git add .
   git rebase --continue
   

   重复这个步骤直到所有冲突解决完成。
5. 最后将变基后的feature分支推送到远程（需要强制推送，因为变基改变了提交历史）：

   git push origin feature/123 --force-with-lease
   

   用--force-with-lease比单纯的--force更安全，能避免覆盖其他人对该分支的修改。

这样操作后，你的feature分支会基于最新的develop分支重新排列提交，不会产生反向合并的记录，PR合并到develop时也会是干净的线性历史。

如果已经发生了反向合并，怎么修正？ #

如果已经出现了develop合并到feature的记录，你可以重置分支并重新同步：

1. 查看feature分支的提交历史，找到反向合并之前的那个提交哈希值：

   git log --oneline
   

2. 重置feature分支到该提交（注意：这会丢弃合并后的所有修改，确保你已经备份或确认不需要这些内容）：

   git reset --hard <目标提交哈希>
   

3. 然后按照上面的rebase步骤同步develop分支，再强制推送即可。

一个小澄清 #

即使你的feature分支有了develop的合并记录，当你合并PR到develop时，develop分支并不会重复接收自己的代码——Git会自动识别并只合并feature分支的新增变更。只是feature分支的提交历史会多一条合并记录而已，不会影响最终的代码结果。

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