Git revert与merge操作组合导致文件丢失的问题咨询

现象原因解析 #

Git 的合并逻辑是基于变更历史追溯，而非单纯对比两个分支的当前文件状态。把你的操作对应到提交链上就能清晰理解：

• 提交 M1：master 分支添加 new_file
• 提交 M2：master 分支执行 git revert M1，生成一个「删除 new_file」的变更提交
• 从 M2 切出 feature/2 分支，此时两个分支的共同祖先就是 M2
• 在 feature/2 分支同样 revert M1，生成提交 F1——这个提交的变更内容也是「删除 new_file」（因为 revert 是撤销原提交的操作，原提交是添加文件，所以 revert 对应删除文件），此时 feature/2 和 master 状态一致，都没有 new_file
• 你在 feature/2 重新创建 new_file 并提交 F2，此时 feature/2 相对于共同祖先 M2 的变更是「添加 new_file」

但 Git 会识别到：这个「添加 new_file」的操作早在 M1 就执行过，且 master 已经通过 M2 明确撤销了这个操作。合并时 Git 判定这是「已被撤销的重复变更」，因此自动忽略了 F2 的添加操作，导致合并后 master 仍然没有 new_file。

处理方案（无配置可直接修改此行为） #

这是 Git 合并逻辑的核心设计，没有现成的 Git/SourceTree 配置能直接改变这个行为，你可以用以下方式手动处理：

• 直接在 master 补加文件：既然合并没带过来，直接在 master 分支重新创建 new_file 并提交即可，操作最简单。
• 用变基替代合并：把 feature/2 的提交重新应用到 master 最新状态上，让 Git 重新识别添加文件的变更：

  git checkout feature/2
  git rebase master
  git checkout master
  git merge feature/2
  

• 强制生成合并提交并手动处理：执行合并时加 --no-ff 参数强制创建合并节点，之后手动将 feature/2 的 new_file 复制到 master 分支，再完成合并提交：

  git checkout master
  git merge --no-ff feature/2
  # 手动复制new_file到master，然后提交合并结果
  

内容的提问来源于stack exchange，提问作者Vladislav Tesařík