GitLab带Squash的Merge Commit底层逻辑及相关疑问解析

测试场景 #

空仓库中执行以下操作：

• 提交初始提交，备注为direct commit to branch（哈希值34b29e2b）
• 创建分支b-4，并在该分支上完成两次提交
• 通过GitLab的「带Squash的Merge Commit」方式将b-4合并到main分支

GitLab界面显示的合并后提交历史：

Merge branch 'b-4' into 'main'  d08bf37f
Squashed commit                 ebc509c2
direct commit to branch         34b29e2b

执行git log --graph --decorate后，预期得到线性提交树，但实际为非线性结构，且顶层合并提交包含Merge: 34b29e2 ebc509c行。

疑问解答 #

1. 提交树为何不是线性的？ #

纯Git的squash merge默认是把分支的所有提交压缩成一个新提交，直接追加到目标分支，形成线性历史。但GitLab的「带Squash的Merge Commit」并非这种纯线性压缩，它本质是先将分支提交压缩为一个临时提交，再基于这个临时提交和目标分支做一次强制非快进合并，因此会产生包含合并节点的非线性结构。

2. 顶层合并提交为何带有Merge: 34b29e2 ebc509c行？ #

Merge: <父提交1> <父提交2>是Git合并提交的核心标识，说明该提交存在两个父节点：

• 34b29e2是main分支合并前的最后一个提交（即初始提交）
• ebc509c是b-4分支被压缩后的临时提交
  这个顶层提交是将这两个节点合并的产物，因此会显示该行。

3. 底层实际执行了哪些操作？ #

GitLab的底层执行步骤大致如下：

1. 切换到main分支，拉取最新状态
2. 将b-4分支的所有提交压缩为一个新的临时提交（即ebc509c2，备注为Squashed commit）
3. 以main分支当前头节点（34b29e2b）和临时压缩提交为双父节点，创建新的合并提交（d08bf37f，备注为Merge branch 'b-4' into 'main'）
4. 更新main分支的头指针指向该合并提交
5. 清理临时压缩提交的分支引用（该提交仍会保留在Git对象库中，直到被垃圾回收）

4. 如何用纯Git复现该行为？ #

通过以下命令可手动复现：

1. 切换到main分支：

   git checkout main
   

2. 执行squash合并并生成压缩提交：

   git merge --squash b-4
   git commit -m "Squashed commit"
   

   记录该压缩提交的哈希值（假设为ebc509c2）
3. 回退到main分支合并前的状态：

   git reset --hard HEAD~1
   

4. 基于压缩提交创建强制非快进合并提交：

   git merge --no-ff -m "Merge branch 'b-4' into 'main'" ebc509c2
   

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