Git合并提交的diff与squash提交的diff是否始终一致？

背景场景 #

假设一个Git仓库的main分支初始结构如下：

A --> B

基于main分支的HEAD创建特性分支，并在该特性分支上添加两次提交，此时分支结构变为：

A --> B
       \
        C --> D

两种合并方式后的分支结构 #

1. Squash变基合并到main分支
   合并后main分支结构变为：

A --> B --> E

（其中E是将特性分支上的C、D两次提交压缩合并后的单一提交）

2. 普通合并提交到main分支
   合并后分支结构如下：

A --> B   - -  (m)
       \       /
        C --> D

（其中(m)是连接main和特性分支的合并提交）

核心问题 #

我们能否得出结论：合并提交(m)的diff始终与压缩提交E的diff完全一致？

答案：不能 #

存在多种情况会导致两者的diff不一致：

• 冲突处理方式不同：如果在执行两种合并操作时遇到相同冲突，若开发人员采用了不同的冲突解决方案，最终提交E和(m)的文件内容会产生差异，对应的diff自然不一致。

• Diff展示逻辑差异：默认情况下，使用git show查看合并提交(m)时，Git会展示该提交与两个父提交（B和D）的组合diff；而查看压缩提交E时，仅展示其与父提交B的差异。即使最终文件内容完全一致，两者的diff输出格式和内容范围也不相同。只有通过git diff m^ m指定对比合并提交与B的差异时，结果才会和git diff B E一致。

• 特性分支内的变更抵消：若特性分支中包含互相抵消的提交（比如先添加某行代码，随后又删除该行），压缩提交E会直接忽略这些无意义的中间变更；而合并提交(m)虽然最终文件内容与E一致，但在查看其组合diff时，可能会显示这些中间变更的痕迹，导致diff展示内容不同。

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