Squash and merge与Regular merge对比：对main分支提交历史的影响

合并前的提交基线 #

Before merge:
main:     A---B---C
feature:      \-D---E---F

两种合并方式对main分支提交历史的差异 #

1. 常规合并（Regular Merge） #

常规合并会在main分支生成一个新的合并提交G，这个提交会保留feature分支所有独立提交（D、E、F）的关联关系，main分支的提交历史会呈现分叉再汇合的结构：

After regular merge:
main:     A---B---C-------G
feature:      \-D---E---F-/

• main分支会完整保留feature分支上的每一次提交记录，能清晰追溯feature分支的分步开发轨迹。
• 合并提交G会标记两个分支的合并节点，方便后续定位代码变更的来源分支。

2. 压缩合并（Squash and Merge） #

压缩合并不会将feature分支的独立提交带入main分支，而是把D、E、F这几次提交的所有代码变更打包成一个全新的单一提交G'，直接追加到main分支的末尾：

After squash merge:
main:     A---B---C---G'
feature:      \-D---E---F

• main分支的提交历史是完全线性的，不会出现分叉，所有来自feature分支的变更都被整合在一个提交里。
• feature分支的原始提交记录（D、E、F）不会出现在main分支的历史中，从main分支看不到feature分支的中间开发细节。

压缩合并的核心作用 #

虽然两种合并后main分支的提交总数都是4次，但压缩合并实现了两个关键效果：

• 简化主干提交历史：把feature分支上的细碎临时提交（比如调试、小修改、中间版本）合并成一个逻辑完整的功能提交，让main分支的历史更简洁、聚焦于功能级别的迭代，避免被零散的开发细节干扰。
• 隔离分支开发轨迹：main分支只记录最终的功能整合结果，不会引入feature分支的中间过程记录，适合需要保持主干分支历史规整、清晰的场景（比如对外展示版本迭代线、简化团队协作中的历史追溯）。

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