Git递归合并提交与Squash合并提交有何区别？适用场景是什么？

递归合并和Squash合并不是同一事物，结合你给出的场景（feature分支含提交A、B、C，main分支含提交1、2，feature从提交1分出），两者的差异和适用场景如下：

核心差异对比 #

递归合并（默认git merge，递归为默认合并策略） #

执行递归合并后，main分支会新增一个合并提交，这个提交有两个父节点：main分支的最后一个提交2，以及feature分支的最后一个提交C。

• 原feature分支的提交A、B、C会完整保留在仓库的提交历史中，通过git log可以看到这些提交的存在，也能看到合并提交的关联关系。
• 合并提交会明确记录“feature分支合并入main分支”这个操作事件。

Squash合并（git merge --squash） #

执行Squash合并时，Git会把feature分支上A、B、C三个提交的所有变更打包成一个普通提交（而非合并提交），然后将这个提交应用到main分支上。

• 原feature分支的A、B、C提交不会出现在main分支的历史中，main分支只会看到这个新的打包提交，且该提交只有一个父节点（main分支的提交2）。
• 相当于把开发过程中的零散提交“抹平”，只保留最终的功能变更结果。

关键区别总结 #

• 历史记录完整性：递归合并保留完整的开发细节提交；Squash合并只保留功能级别的最终提交。
• 提交类型：递归合并生成带双父节点的合并提交；Squash合并生成普通的单父节点提交。
• 后续协作影响：如果之后要基于main分支继续开发原feature相关内容，递归合并因为有历史关联，后续合并冲突概率更低；Squash合并则可能因为丢失了原提交的关联，导致后续合并时重复处理变更，冲突风险更高。

何时选择哪种合并方式 #

偏好递归合并的场景 #

• 团队需要完整追踪功能开发的每一步，方便后续定位问题（比如某个bug可以追溯到具体的A/B/C提交）。
• 项目重视提交历史的可追溯性，需要保留功能开发的完整上下文。
• 后续可能需要对原feature分支的单个提交进行cherry-pick、回退等操作。

偏好Squash合并的场景 #

• 希望main分支的提交历史更简洁，不想被开发过程中的临时提交（比如调试、拼写修复）打乱整体历史逻辑。
• 个人项目或小型团队，更关注功能交付结果，不需要太细致的提交追踪。
• feature分支的提交零散、逻辑不清晰，合并后压缩成一个清晰的功能提交更便于维护。

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