为何GitHub会出现循环合并？我的操作引发双向合并的原因
2026-5-21
为什么GitHub会出现这种“循环合并”？
这事儿我太熟了——你这是因为操作顺序搞反了，不小心把两个分支互相合并了，才出现了看起来像“循环合并”的情况。咱们一步步拆解你的操作，看看问题出在哪：
你的操作到底发生了什么？
你的初衷是把分支A合并到分支B，但遇到冲突后，执行的命令其实走偏了：
git checkout A：切换到分支A，这一步没问题。git merge B：这一步是把分支B的所有内容合并到了A里，而不是解决“A合并到B”的冲突。这时候A分支已经包含了B的全部代码，加上你手动解决的冲突，A现在是「A原代码 + B原代码 + 冲突解决结果」。git checkout B：切回目标分支B。git merge --no-ff A：把已经合并过B的A分支合并到B里。这时候B分支的内容变成「B原代码 + 合并了B的A代码」，等于B也包含了A的所有内容（包括A刚合并的B内容）。git push origin B：推送到远程B分支。
这时候你切换回A分支，会发现A里已经有B的内容（因为你之前执行了git merge B），而B里也有A的内容，看起来就像是“B合并到A，A又合并到B”，形成了双向的合并记录，也就是你看到的“循环合并”。
正确解决PR冲突的姿势（A→B）
其实解决PR冲突的核心是让待合并的分支（A）先同步目标分支（B）的最新内容，解决冲突后再合并到B，或者直接在目标分支（B）上合并待合并分支（A）并解决冲突。两种方式都可以，选你习惯的：
方式一：在分支A上同步B的内容
- 切换到A分支：
git checkout A - 拉取远程B分支的最新内容并合并到A：
git merge origin/B - 此时会弹出冲突提示，手动解决所有冲突后，提交合并结果：
git add .→git commit -m "Resolve conflicts with B" - 把更新后的A推送到远程：
git push origin A - 回到GitHub的PR页面，此时冲突应该已经消失，直接点击合并按钮即可完成A→B的合并。
方式二：直接在分支B上合并A
- 切换到B分支：
git checkout B - 拉取远程B的最新内容：
git pull origin B - 合并A分支到B：
git merge A - 手动解决冲突，提交合并结果：
git add .→git commit -m "Merge A into B, resolve conflicts" - 推送到远程B分支：
git push origin B - 此时GitHub上的PR会自动检测到B已经包含A的内容，标记为合并完成。
总结一下
你遇到的“循环合并”本质不是真的循环，而是不小心执行了双向合并（B→A，再A→B），导致两个分支互相包含了对方的合并历史。只要调整操作顺序，让合并方向保持单一（A→B），就能避免这种情况。
内容的提问来源于stack exchange，提问作者kaizer
相关产品推荐
相关产品推荐
