Git合并疑问：feature_branch合并后fileA行数为何未增加？

这个问题的关键在于Git的三路合并逻辑，以及你的主项目提交历史里藏着的特殊操作——测试项目因为历史干净，表现完全符合预期，但主项目的复杂历史让Git做出了和你直觉相反的自动合并决策。咱们一步步拆解：

核心原因：Git合并的判断逻辑 #

Git的合并依赖三路合并：它会先找到master和feature_branch的共同祖先提交，然后对比祖先版本与两个分支的版本差异，自动合并变更。出现你描述的情况，大概率是主项目历史中存在让Git判断「feature分支的变更已经被master抵消」的操作。

1. master分支曾反向撤销过feature分支的变更 #

最常见的场景是：

• 共同祖先的fileA是1000行
• 曾经有一个提交在master上给fileA增加了50行（变成1050行）
• 之后有人用git revert撤销了这个提交，fileA回到1000行
• 你的feature_branch恰好基于那个「增加50行」的提交创建，或者直接包含了那50行的变更

此时Git对比三个版本：

• 祖先：1000行
• master：1000行（主动撤销了增加操作）
• feature_branch：1050行（保留了增加操作）

Git会认为master已经主动放弃了这个变更，所以自动合并时会保留master的版本，且不会触发冲突——它觉得这是「撤销后不再应用」的预期逻辑。

2. 分支拓扑导致共同祖先版本比master新 #

如果feature_branch不是从当前master拉取的，而是从很久之前的master分支创建的：

• 比如半年前你拉了feature分支，之后master经过多次合并、回退，其中某次操作把fileA从1050行改回了1000行
• feature分支的共同祖先是半年前的master（当时fileA是1050行）

此时Git对比：

• 祖先：1050行
• master：1000行（从祖先版本删除了50行）
• feature_branch：1050行（和祖先版本一致）

Git会认为master对fileA做了「删除50行」的变更，而feature分支没有任何修改，所以合并后保留master的1000行版本。

具体排查步骤 #

你可以通过以下命令定位问题根源：

1. 找到共同祖先提交：

   git merge-base master feature_branch
   

   记下输出的commit ID。

2. 对比三个版本的fileA：
   先看行数差异：

   # 查看共同祖先的fileA行数
   git show <祖先commit>:fileA | wc -l
   # 查看当前master的fileA行数
   wc -l fileA
   # 查看feature_branch的fileA行数
   git show feature_branch:fileA | wc -l
   

   再看具体内容差异：

   git diff <祖先commit> master fileA
   git diff <祖先commit> feature_branch fileA
   

   这能帮你清晰看到两个分支相对于祖先的变更方向。

3. 查看fileA的提交历史：

   git log --oneline fileA
   

   重点检查是否有revert、reset或者其他修改行数的提交，尤其是涉及删除50行的操作。

测试项目的正常逻辑 #

你的测试项目因为历史非常干净：

• 共同祖先就是master初始的1000行版本
• feature分支直接在这个基础上增加了50行
• Git三路合并时，会把master的「无变更」和feature的「增加50行」合并，自然得到1050行的结果

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