未合并至master的分支提交却出现在master中的Git问题求助

这种情况确实挺让人困惑的——明明没把目标分支合并到master，结果提交却出现在里面了。我来分享几个排查方向，帮你找到问题根源：

1. 检查隐性的提交迁移操作 #

有时候提交出现在master里，不一定是通过常规的git merge操作，可能是其他方式迁移过去的：

• 用git reflog show master查看master分支的所有操作记录，包括被撤销的合并、重置、cherry-pick等操作。这里能找到所有影响过master分支的历史动作，比如有没有人用git cherry-pick [提交哈希]把目标分支的提交单独挑到master里？
• 运行git log --merges master，查看master上所有的合并提交，仔细检查每个合并提交的父节点，看看有没有包含目标分支的提交（有些合并可能没标注明确的分支名）。

2. 验证提交的真实来源 #

有时候看起来是目标分支的提交，可能是被重复提交或者复制的：

• 找到那个出现在master里的提交哈希（比如abc123），运行git branch --contains abc123，看看哪些分支包含这个提交，确认是否真的只有master和目标分支存在该提交？
• 用git show abc123查看提交的详细信息（作者、时间、变更内容、备注），和目标分支上的对应提交做对比，看看是不是完全一致？有没有可能是有人手动重做了相同的变更，然后直接提交到master了？

3. 排查GitLab的自动化流程与权限设置 #

有没有可能是CI/CD脚本或者权限漏洞导致的？

• 查看GitLab项目的CI/CD流水线历史，看看有没有针对master分支的流水线执行过合并、cherry-pick之类的操作——比如有没有脚本误把stage分支的变更同步到master？
• 检查GitLab的保护分支设置，确认master分支的合并/推送权限是不是仅开放给特定人员，有没有人绕过了MR流程，直接把提交推送到master了？

4. 检查分支历史改写或重命名情况 #

目标分支有没有被重命名，或者master的历史被人为改写过？

• 用git log --oneline master | grep "目标分支相关的关键词"，看看有没有相关的提交备注，可能合并的时候没明确标注分支名，导致你没注意到？
• 运行git fsck --full，检查仓库里的悬空提交或异常对象，这能帮你发现是否存在历史被篡改的痕迹。

5. 对比本地与远程仓库的一致性 #

有时候本地仓库的历史可能和远程GitLab上的不一致：

• 先拉取最新的远程分支：git fetch origin，然后用git diff origin/master master对比本地master和远程origin/master的差异，确认是不是本地历史有问题？
• 直接在GitLab上找到那个提交，查看它关联的合并请求（MR），看看有没有可能是创建MR时选错了目标分支，误合并到master了？

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