Git回退提交后cherry-pick，合并分支时提交丢失问题排查

核心原因 #

Git的合并逻辑不是基于提交ID，而是基于提交的内容变更。你的操作流程里，Git会判定提交a'的内容已经在分支B的历史中被处理过（即便后续被回退，合并记录仍会留下追踪痕迹），因此二次合并时会自动跳过这些变更，最终导致你看到的“提交丢失”。

逐步骤拆解Git的判断逻辑 #

1. 步骤1-3的状态：
   • 分支A创建提交a，分支B合并A后，B的历史已包含a的内容变更；随后你通过回退操作（如git reset或git revert）撤销了a的内容，此时B的当前状态不含a，但Git的合并追踪系统会记录：B曾经合并过包含a内容的提交。
2. 步骤4的状态：
   • 分支A回退a后，用git cherry-pick a生成提交a'——a'的内容和a完全一致，仅提交ID不同，本质是同一变更的重复提交。
3. 步骤5的二次合并：
   • Git执行三方合并时，会对比三个版本：B的当前提交、A的当前提交（含a'）、以及B和A的共同祖先提交（即第一次合并A之前的B的提交）。
   • Git计算差异：共同祖先到A的变更为a'的内容（和a完全一致）；共同祖先到B的变更为“添加a内容后又移除a内容”的净变更。
   • Git判定：a'的内容已在B的历史中出现过（即使后续被撤销），因此认为该变更已被处理，不会将a'的内容合并到B中。

对Git Merge文档的误解纠正 #

你提到的文档中“将topic分支的变更重放到master分支”是简化的通俗表述，实际Git的合并是三方内容合并：它会对比两个分支相对于共同祖先的内容差异，再合并这些差异，而非直接重放提交。若某个变更在目标分支的历史中已存在（无论后续是否被移除），Git都会跳过该变更。

解决方法 #

若需要将a'的内容合并到分支B，可采用两种方式：

• 直接cherry-pick a'到B：切换到B后执行git cherry-pick <a'的提交ID>，强制将a'的内容应用到B，会明确添加该变更的提交记录。
• 用rebase替代合并：切换到分支A后执行git rebase B，将A的提交（包括a'）基于B的最新提交重新生成，再切换到B执行git merge A，此时Git会判定这些为全新变更，不会跳过。

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