Git静默回滚提交排查：合并提交为何覆盖未冲突文件变更？

这种情况的核心原因是Git的三路合并逻辑与分支历史结构共同作用的结果，再加上合并过程中被忽略的变更预览。让我们一步步拆解细节：

1. 分支历史与合并基础的关键细节 #

你的提交历史结构可以简化为：

O (共同祖先)
| \
A (包含修复的主分支提交) |
| /
B (合并提交)

这里的核心问题是：并行分支是从共同祖先O直接分出的，完全没有包含提交A的任何变更。当你将这个并行分支合并到当前指向A的主分支时，Git会执行三路合并：

• 找到两个分支的最近共同祖先（LCA）：也就是O
• 对比O与主分支顶端A的变更：得到A对目标文件的修复修改
• 对比O与并行分支顶端的变更：该分支未修改A涉及的文件，这部分变更为空

按常规逻辑，Git应该保留主分支A的修改，但实际出现了回滚，背后有具体的触发原因：

2. 静默回滚的核心触发点 #

（1）PR合并时的无意识选择 #

你提到PR中已显示文件变更但被开发者忽略——这是最常见的原因。即使Git没有检测到行级冲突，PR界面通常会展示合并后的文件变更预览。如果开发者在合并时无意识地选择了**"接受源分支的所有变更"**（也就是并行分支的版本，即O时期的文件状态），而非默认的合并逻辑，就会直接回滚A的变更。

（2）隐式的文件状态重置 #

另一种可能是：并行分支虽然没有直接编辑目标文件，但存在隐式的文件状态重置（比如通过git checkout O -- <目标文件>将文件恢复到O的版本）。这种操作Git会识别为"文件内容回滚到祖先版本"，而非"无变更"。此时三路合并时，Git会认为并行分支对该文件的变更是"恢复到O"，与主分支的"修改到A"属于同文件的不同变更，若没有显式的行级冲突，Git可能会默认选择并行分支的版本。

3. 是否与历史提交有关？ #

是的，完全与历史提交的结构有关：

• 并行分支从A创建前的O分出，导致合并时的共同祖先为O，而非A之后的节点。如果并行分支是在A之后分出的，合并时就会自动包含A的变更，不会出现回滚。
• 提交A是主分支上的单向变更，没有在并行分支中同步，这才导致合并时出现"主分支修改 vs 并行分支未修改/回滚"的特殊场景。

额外验证命令 #

你可以通过以下命令确认合并前后的变更细节：

# 查看共同祖先O与提交A的目标文件差异
git diff O A -- <目标文件路径>
# 查看共同祖先O与并行分支顶端的目标文件差异
git diff O <并行分支顶端提交哈希> -- <目标文件路径>
# 查看提交A与合并提交B的目标文件差异
git diff A B -- <目标文件路径>

如果最后一条命令显示目标文件回滚到了O的状态，就能确认合并时确实选择了并行分支的版本。

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