这事儿其实是Git合并机制的设计逻辑导致的，咱们结合你的操作场景一步步说清楚：

先还原下你的操作背景：

提交历史如下：

• 51c3dd7 (HEAD -> master) add c
  | * ded49bb (my_branch) add b
  |/
• f3cea38 add a
  你执行了git merge --no-commit --no-ff my_branch进入MERGING状态，随后取消暂存了所有内容，最后执行git commit完成合并，结果得到了一个没有任何变更的合并提交。

核心原因：Git的合并提交优先记录分支拓扑关系 #

• --no-ff是关键触发点：这个参数的作用就是强制生成合并提交，哪怕合并过程中没有任何文件内容的变更。它的核心目的是保留分支的历史拓扑——也就是标记「曾经把my_branch分支合并到当前分支」这个事件，而不是简单把my_branch的提交直接追加到当前分支上。
• 取消暂存不影响合并的上下文记录：当你执行git merge --no-commit时，Git已经完成了分支的拓扑计算，确认了这次合并的两个父提交（当前HEAD的51c3dd7和my_branch的ded49bb），只是没自动提交。你取消暂存的只是合并产生的文件变更，但Git内部已经记住了这次合并的父子关系。当你执行git commit时，Git会基于这个已有的合并上下文，创建一个没有文件修改，但包含双父节点的合并提交。
• 空合并提交的实际意义：看起来没内容，但它明确记录了分支合并的时间点和协作路径，在多人协作或者需要追溯代码演进历史时，能清晰展示分支的合并关系，避免历史线混乱。

如果想避免创建这种空合并提交，可以这么做： #

• 合并前先检查分支差异：用git diff master..my_branch看看有没有实际变更，如果没有，直接用git merge --abort取消这次合并操作即可。
• 不需要保留分支拓扑的话，去掉--no-ff参数：如果你的场景不需要保留my_branch的独立分支历史，使用默认的快进合并（git merge --no-commit my_branch），当没有变更时，Git不会生成新的提交。

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