为什么gitlab的MR会默认有一个merge commit

GitLab 默认使用 Merge commit 策略（即 git merge --no-ff），这是一个设计选择。我们来看看背后的原因：

什么是 Merge Commit

# 使用 Merge commit（--no-ff）
* a1b2c3d Merge branch 'feature' into main  ← 这就是 merge commit
|\
| * d4e5f6a feature commit 2
| * b7c8d9e feature commit 1
|/
* 1a2b3c4 main 的上一个提交

# 不使用 Merge commit（fast-forward）
* d4e5f6a feature commit 2
* b7c8d9e feature commit 1
* 1a2b3c4 main 的上一个提交

---

为什么 GitLab 默认创建 Merge Commit

1. 保留分支历史

Merge commit 记录了"这些提交来自一个 feature 分支"这个事实：

Merge branch 'feature/login' into 'main'
See merge request !1234

没有它，你无法从 Git 历史中看出哪些 commits 属于同一个功能。

2. 关联 MR 信息

Merge commit message 包含：

• 分支名称

• MR 编号（!1234）

• MR 标题

这使得从 Git 历史直接追溯到 GitLab MR 页面成为可能。

3. 方便回滚整个功能

# 有 merge commit，一条命令回滚整个功能
git revert -m 1 a1b2c3d

# 没有 merge commit，需要逐个回滚
git revert d4e5f6a
git revert b7c8d9e

4. 清晰的审批记录

Merge commit 的 Author 是执行合并的人，代表"谁批准了这次合并"。

---

三种合并策略对比

策略	Git 命令	历史形态	适用场景
Merge commit	git merge --no-ff	保留分支结构	团队协作，需要追溯
Fast-forward	git merge --ff	线性，无合并点	简单的个人分支
Rebase	git rebase + --ff	线性，commits 重写	追求干净历史
Squash	git merge --squash	线性，压缩为一个	一个功能一个提交

---

GitLab 的配置

GitLab 允许在项目设置中修改默认策略：

Settings → Merge requests → Merge method

选项	效果
Merge commit	始终创建 merge commit（默认）
Merge commit with semi-linear history	先 rebase 再 merge commit
Fast-forward merge	仅允许 fast-forward，不创建 merge commit

总结

GitLab 默认创建 Merge commit 是为了：

• 可追溯性：知道哪些提交属于哪个功能

• 关联性：commit 直接链接到 MR

• 可回滚性：一条命令撤销整个功能

• 审批记录：记录谁批准了合并

如果你的团队偏好线性历史，可以在项目设置中改为 Squash 或 Fast-forward 策略。