Git合并疑似丢失变更：为何存在差异的文件未被合并？

核心原因：Git的三向合并逻辑 #

Git合并不是直接对比两个分支的当前版本，而是基于三向合并决策：

1. 找到两个分支的共同祖先提交（BASE）
2. 分别计算：
   • BASE与当前分支（HEAD）的文件差异
   • BASE与待合并分支（OTHER）的文件差异
3. 仅合并那些「在其中一个分支有新增变更、且未被另一分支覆盖」的内容：
   • 如果文件在BASE之后，只有其中一个分支有变更，Git自动采纳该分支的版本，不会触发合并提示
   • 如果之前branch1已经合并到branch2，Git会认为branch1中已合并的变更属于HEAD（branch2）的一部分；后续若branch2对这些文件的变更覆盖了之前的合并内容，或branch1未对文件做新修改，Git会判定无需再次合并

排查与解决步骤 #

1. 确认共同祖先与变更差异 #

首先找到两个分支的共同祖先：

git merge-base <branch1> <branch2>

替换<branch1>和<branch2>为你的分支名，得到祖先提交ID（记为<BASE>）。

分别对比三个版本的文件差异：

# 查看branch1相对于祖先的变更
git diff <BASE> <branch1> -- file.cpp
# 查看branch2相对于祖先的变更
git diff <BASE> <branch2> -- file.cpp
# 查看两个分支当前的差异
git diff <branch2> <branch1> -- file.cpp

通过这三个diff可以明确：

• branch1的变更是否已经被合并到branch2中
• 是否存在未被合并的新增变更

2. 手动处理未合并的变更 #

如果确认存在未被合并的有效变更，可通过以下方式处理：

• 直接覆盖版本：将branch1的文件版本直接应用到当前分支（branch2）：

  git checkout <branch1> -- file.cpp
  

• 强制创建合并提交：如果是快进合并导致Git跳过，强制生成合并记录：

  git merge --no-ff <branch1>
  

• 选择性应用提交：用cherry-pick将branch1中未合并的单个提交逐个应用：

  git cherry-pick <commit-id>
  

3. 修复补丁应用报错问题 #

git diff <branch1>..<branch2>生成的补丁包含分支端点的所有差异，可能包含已合并过的内容，导致git apply报错。正确的做法是基于共同祖先生成补丁：

git diff <BASE> <branch1> > update.patch

再用git apply update.patch应用，报错会大幅减少。

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