GitLab Merge Request重复显示已合入提交与变更问题

问题根因 #

这个现象不是GitLab故障，核心原因是Squash commits合并生成的全新提交仅存在于目标分支master，没有同步回源分支develop，导致两个分支的提交基线断裂。
第一次提MR勾选Squash合并时，GitLab会把develop分支上所有待合入的提交压缩为1个独立的新提交写入master，这个squash生成的新提交从始至终不会出现在develop分支上。此时Git计算两个分支的共同祖先时，会定位到第一次squash之前的分叉节点，后续再提MR时，Git会把develop上从这个旧分叉节点往后的所有提交都判定为「待合入变更」，自然就包含了上一次MR已经合过的所有历史提交。
之前操作没出现问题，基本都是因为当时合并完成后无意间做了分支同步，或是用了普通merge commit模式（该模式合并后两个分支的提交历史可正常追溯共同祖先，不会出现基线断裂）。

常见触发场景 #

• 勾选Squash完成master合并后，未将master的最新代码同步回develop，直接在原develop分支上继续开发提新MR
• 项目开启了Squash合并后默认删除源分支的配置，但实际长期复用develop作为固定集成分支，没有按预期删除重建
• 本地develop分支未拉取远端最新状态，基于过时的提交节点开发后推送到远端，导致共同祖先计算错位

修复当前异常MR的操作步骤 #

1. 切换到本地develop分支并拉取远端最新状态：
   git checkout develop && git pull origin develop
2. 将master分支的最新代码正常合并到本地develop，不要加squash、rebase参数，保留默认合并提交即可：
   git merge origin/master
   如果出现代码冲突，按正常流程解决冲突后提交合并结果。
3. 将合并后的develop分支推送到远端：
   git push origin develop
   推送完成后刷新MR页面，之前重复展示的已合入历史提交、变更会自动消失，仅保留两次合并之间develop上新增的有效变更。

长期规避方案 #

• 如果团队固定复用develop作为集成分支：每次Squash合入master完成后，必须第一时间将master的最新代码同步回develop，保证两个分支的共同祖先始终对齐
• 工作流优化：不要长期复用固定开发分支提MR，每次开发新需求/修复问题都从最新的master切独立的临时feature分支，提MR勾选Squash合入后直接删除临时feature分支，从根源上避免基线不对齐问题
• 项目配置调整：固定使用Squash合并模式的团队，可以在项目合并设置中开启「合并完成后自动删除源分支」，强制使用临时分支提MR

注意：同步master代码到develop时不要用squash或变基（rebase）操作，使用默认的merge生成合并提交即可，否则依然会出现提交历史无法关联、Git计算共同祖先错位的问题。

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