GitLab新建合并请求自动添加非必要main分支提交异常如何处理

• 提交哈希匹配被Git判定为重复提交：Git的提交哈希是基于提交内容、父提交、时间戳等信息生成的唯一标识，只要被自动cherry pick的提交本身已经存在于main分支的提交链中，合入MR时Git会自动识别为重复提交直接跳过，不会重复写入提交历史，也不会重复执行代码变更，属于Git的内置去重逻辑。
• 快进合并策略导致提交不重复写入：如果仓库MR默认合入策略配置为快进合并（Fast-Forward），且你的功能分支本身就是基于main分支最新节点拉取的，合入时Git只会把main分支的HEAD指针移动到你功能分支的最新提交，已经存在于main的提交自然不会重复出现在历史记录里。
• cherry pick变更被冲突解决逻辑覆盖：如果自动cherry pick的提交和你的分支代码存在冲突，GitLab合入时如果触发了自动冲突解决，或者你手动解决冲突时完全覆盖了该提交的所有变更，最终合入的代码就不会保留对应修改，提交历史也不会留下相关记录。
• Squash压缩合并提交导致记录消失：如果你的MR开启了合并时压缩提交（Squash Commits）配置，GitLab会把你MR里的所有提交（包括自动cherry pick的提交）合并成1个全新的提交合入main，如果你自己的代码变更覆盖了cherry pick的内容，最终就只会显示压缩后的单条提交记录，看不到原cherry pick的提交痕迹。

• 校验提交是否已存在于main分支：本地拉取最新main分支后执行git log main | grep <目标提交的哈希值>，如果能查到对应记录，说明该提交早已合入main，此次属于正常跳过。
• 检查合入策略配置：进入项目「设置」-「合并请求」-「合并方法」页面查看全局合入规则，再到对应MR的「合入选项」区域查看是否勾选了「压缩提交」「仅允许快进合并」选项，确认是否是策略导致提交被合并/跳过。
• 比对合入前后的代码差异：执行git diff <MR合入前main的最后一个哈希> <MR合入后main的最后一个哈希>，查看差异内容是否包含被cherry pick提交的变更，如果没有说明变更在合入流程中被丢弃。
• 查看MR系统日志：进入MR页面的「活动」-「系统日志」板块，查看是否有冲突自动解决、提交压缩、重复提交跳过的相关系统记录，确认合入过程的具体行为。

• 若确认目标提交已存在于main分支，无需任何处理，属于Git正常逻辑。
• 若提交被压缩且变更丢失，切换到最新main分支后手动执行git cherry-pick <目标提交哈希>，解决冲突后直接推送到main，或发起新的MR合入即可。
• 若冲突解决时变更被覆盖，手动修改代码补充对应变更后提交，发起新MR合入即可。
• 后续发起MR前建议先执行git rebase origin/main把本地分支和远程main同步，可大幅减少GitLab自动cherry pick额外提交的概率。

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