Git合并分支未恢复已删除文件问题及正确恢复方法

Git合并的本质是合并两个分支相对于共同祖先提交的差异，而非直接对两个分支的目录内容做叠加。
对应到你的操作场景，提交链路简化如下：
提交X（两个目标文件正常存在）→ 提交Y（执行删除两个文件的操作）→ 多次后续提交 → 当前master分支HEAD
你从提交X切出新分支时，该分支相对于共同祖先（即提交X）没有产生任何新的变更。切回master执行合并时，Git的差异计算逻辑为：

• master分支相对于提交X，存在明确的“删除两个目标文件”的变更记录
• 新建分支相对于提交X，无任何变更
  最终合并结果会完全保留master分支的现有状态，不会自动回退已经入库的删除操作。多数场景下Git会直接返回Already up to date——毕竟新分支上的所有提交早已经被master的提交历史包含，整个合并操作属于无效操作。

• 对Git合并规则的理解存在偏差：Git不会因为旧分支中存在特定文件，就主动将这些文件同步到当前分支。只有当分支上存在明确的变更记录（比如重新添加被删文件、修改文件内容）时，对应变更才会被合并到目标分支。
• 流程冗余：恢复历史版本中的文件完全不需要新建分支再合并，这套多余的流程因为没有产生实际变更，根本不会对master分支的内容产生任何影响。

根据实际场景选择对应命令即可，全程不需要切换分支：

• 已知删除文件的提交时
  先执行以下命令查找所有删除操作的历史，定位到删除目标文件的提交hash（记为<del_commit>）：

  git log --diff-filter=D --summary | grep delete
  

  从删除提交的父提交（即文件仍存在的版本）将文件恢复到当前工作区：

  git checkout <del_commit>^ -- 目标文件1路径 目标文件2路径
  

  执行完成后文件会直接出现在工作区并自动加入暂存区，正常提交即可完成恢复。
• 仅记得被删文件路径、不记得删除提交时
  执行命令查找最后一次包含该文件的提交hash（记为<last_exist_commit>）：

  git rev-list -n 1 HEAD -- 被删文件的相对路径
  

  直接从该提交恢复对应文件即可：

  git checkout <last_exist_commit> -- 被删文件的相对路径
  

• 需要整体回退分支到文件存在的历史版本时（谨慎使用，会丢弃目标提交之后的所有提交记录）

  git reset --hard <目标历史提交hash>
  

注意：所有checkout恢复文件的操作，都会直接覆盖对应路径下的未提交修改，执行前请确认对应路径没有需要保留的未保存内容。

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