Git普通合并与squash合并的差异及重复合并无冲突原因

为什么Git允许执行普通合并？ #

Git的合并逻辑核心是追踪提交历史的父子关系，而非文件内容是否一致。当你对A到B的PR执行squash合并时，Git只是把A分支的所有提交内容打包成一个全新的提交放到B分支上，但A分支本身的原始提交历史完全没被修改，同时B的历史里也不会记录“已合并A的原始提交”这件事。

在Git看来，B分支的提交历史里从来没有包含过A的那些原始提交——squash生成的新提交和A的原始提交是完全独立的（哪怕内容一致，提交哈希也完全不同）。所以当你再次发起A到B的PR时，Git会判定B尚未合并过A的提交历史，自然允许你执行普通合并操作。

为什么不会产生冲突？ #

因为第一次squash合并已经把A分支的所有变更同步到了B分支里。当你再次尝试合并A的原始提交时，Git会对比B的当前状态（已经包含A的所有变更）和A分支提交的内容，发现两者的文件内容完全一致。这种情况下，Git会自动识别出这些变更已经存在，合并过程不会触发冲突：

• 如果B分支在squash合并后没有新增提交，Git会直接执行快进合并，把A的提交历史直接追加到B上；
• 如果B分支有新提交，Git会生成一个空的合并提交（没有实际变更，只是把A的历史合并进来）。

需要注意的是，这种操作其实是冗余的，会导致B分支的历史出现重复的变更记录，实际工作中不建议这么做。

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