GitLab：执行压缩合并（squash）为何会生成两个提交？

我之前维护项目时也碰到过这个情况，其实这两笔提交的本质和存在的意义是完全不同的，咱们一步步说：

先搞懂这两笔提交是什么 #

• 标题为 Merge branch '123-branch-name' into 'dev' 的是合并提交（Merge Commit）：它是Git用来标记「把某个分支的变更合并到目标分支」这个操作的提交，本身不包含新代码变更，只是记录合并动作的元数据（比如合并时间、操作人、来源分支）。
• 标题是完整Issue名称的是压缩后的Squash提交：它是把你在MR分支上的多笔零散提交，打包合并成的一笔新提交，包含了这个Issue对应的所有代码变更。

为什么会同时出现？ #

当你勾选「压缩提交」并执行合并时，Git平台（比如GitLab/GitHub）默认执行了两个步骤：

1. 先将MR分支上的所有提交压缩成一笔全新的、包含完整变更的提交（就是你看到的Issue标题那笔）；
2. 再创建一个合并提交，把这笔压缩后的提交正式合并到目标分支dev里。

这种设计的核心意义 #

这么做其实是为了平衡提交历史的整洁性和可追溯性，具体来说有这几个好处：

• 保留合并链路的上下文：合并提交能清晰告诉你「这个功能是从哪个分支合并进来的」「谁在什么时候合并的」，日后排查问题或者回溯需求时，能快速关联到对应的MR和Issue讨论记录，不会让历史变成一笔笔孤立的功能提交。
• 让主分支历史更干净：Squash提交把你开发过程中零散的「修复拼写错误」「调试日志」这类临时提交都打包成了一笔对应完整Issue的提交，主分支dev的提交历史会更有条理，每一笔都对应一个明确的功能或修复。
• 兼容不同的查看需求：
  • 如果你想快速梳理项目的功能迭代，直接看Squash提交就够了，每一笔都对应一个完整的需求；
  • 如果你需要排查合并相关的问题（比如合并时是否有冲突、为什么某个变更会出现在主分支），合并提交就能提供关键的操作上下文。

补充一句：有些平台其实支持选择「仅生成Squash提交，不创建合并提交」，但你遇到的情况是平台默认保留了合并提交，目的就是最大化兼顾历史的可读性和可追溯性。

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