GitLab禁用直接推master时，如何通过合并请求正确解决分支冲突？

问题核心 #

• 仓库维护release和master两个长期分支，需定期将release合并至master
• 仓库禁用直接推送master，常规冲突解决流程因需推master无法完成
• 尝试通过中间分支resolve-conflict合并后，原合并请求MR1仍显示冲突
• 疑问：合并设置从「仅快进」改为「合并提交」是否引发该问题？

底层逻辑解释 #

你遇到的MR1冲突残留问题，根源是两个合并请求的基准分支不匹配：

• MR1的对比基准是原始的release和master分支
• 你创建的resolve-conflict分支是本地master与release的合并结果，合并到master后，master的HEAD更新了，但release分支本身没有任何变化——MR1依然在对比旧版master和release，冲突点自然还存在。

正确解决方案（无需直接推master） #

不需要创建两个MR，直接基于master分叉临时分支处理冲突，再提交MR即可：

1. 拉取远程最新分支数据

git fetch origin

2. 基于远程master创建临时冲突解决分支

git checkout -b fix-release-conflict origin/master

3. 合并远程release到临时分支，触发冲突处理

git merge --no-ff origin/release

4. 手动解决所有冲突，完成合并提交

# 冲突解决后执行
git add .
git merge --continue
# 若merge --continue报错，直接提交合并结果
git commit -m "Merge origin/release into master, resolve conflicts"

5. 推送临时分支到远程

git push origin fix-release-conflict

6. 在GitLab上创建该临时分支到master的合并请求，同时关闭原MR1

合并设置的影响说明 #

将合并设置从「仅快进」改为「合并提交」不会导致该问题：

• 「仅快进」要求合并时无冲突，只能线性推进分支；「合并提交」允许创建新的合并节点，这和你本地执行merge --no-ff的行为一致。
• 你的问题完全是流程操作不当导致，与合并设置无关。

补充：已合并MR2后的处理 #

如果已经将resolve-conflict合并到了master，只需关闭原MR1，重新基于最新的master和release创建合并请求即可——此时master已包含之前的合并内容，新MR会自动识别冲突已解决（若release无新提交）。

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