合并方式怎么选，快进与保留历史各有代价

定义框：合并方式（merge method）是代码托管平台在合并请求合入目标分支时采用的 Git 策略。极狐GitLab 支持三种：合并提交、合并提交与半线性历史、快进式合并，并叠加"合并时压缩"开关。它决定了主干历史的形状，也间接决定 git log、git bisect 和回滚的难易度。

很多团队对合并方式的认知停留在"平台默认给什么就用什么"。默认策略会为每次合并创建一个合并提交——只要合并请求在跑、主干历史就会以每两三个功能提交配一个合并提交的速度膨胀。历史厚了不是审美问题：git log 查定位变难，git revert 一次回滚可能要同时处理合并提交，出问题时排查半径直接变大。

为什么合并方式值得单独做一次决策

合并方式影响三件事：

1. 历史可读性。合并提交会把"谁在什么时候把哪个分支并进来"记进主干，快进式则只留下功能提交本身。

2. 定位效率。git bisect 在密集的合并提交之间来回跳，定位一段坏代码的成本会被合并提交放大。

3. 回滚粒度。一次功能出问题要回退时，合并提交与压缩提交的回滚路径完全不同。

这也是为什么合并方式属于"平台级约定"——它不是个人偏好，而是全仓库统一的工作流策略，改一次要连历史一起考虑。

一个常见的误判是把它当成纯审美议题："历史好不好看无所谓，代码能跑就行"。但主干历史是事故排查时的第一现场：git blame 跨过合并提交要来回跳，git log --first-parent 的输出直接受合并方法影响，团队里新人理解"这个改动怎么进来的"依赖提交图的形状。合并方式在仓库创建时就该定好，而不是出了一次难查的事故之后才想起来。

三种合并方式怎么配

在极狐GitLab 中进入 设置 → 合并请求 → 合并方法 即可选择，三种方式的边界如下。

1. 合并提交（默认）。等价于 git merge --no-ff，每次合并都产生一个合并提交。优点是完整保留分支拓扑，能看到每个分支从哪里开始、何时合入；代价是主干历史最厚。

# 合并提交策略等价的本地操作
git checkout main
git merge --no-ff feature

2. 合并提交与半线性历史。仍然创建合并提交，但只有能快进时才允许合并——如果源分支基于过时的目标分支，必须先变基。它的好处写在官方文档里：如果合并请求构建成功，目标分支在合并后也能构建成功。适合既想看到分支轨迹、又要求主干每一步都可构建的团队。

3. 快进式合并。不产生合并提交，保留线性历史。工作流策略要求干净提交历史时选它；限制是目标分支一旦有新提交，源分支必须先变基再合。

# 快进式合并等价的本地操作
git checkout main
git merge --ff-only feature

选定方式后建议通过 API 固化到项目模板里，避免新仓库漏配：

curl --request PUT "https://gitlab.example.com/api/v4/projects/<项目ID>" \
  --header "PRIVATE-TOKEN: <令牌>" \
  --data "merge_method=ff"

merge_method 可取 merge（合并提交）、rebase_merge（半线性）、ff（快进）。

叠加项：合并时压缩。项目设置里的"合并时压缩提交"有三档：禁用（所有提交直接进目标分支，保留各自历史）、允许（默认关闭，用户可自行更改）、鼓励（默认开启，用户可关闭）。启用压缩时，源分支的所有提交先合成一个提交，再快进到目标分支。

踩坑提示

• 快进不可用时只能变基。快进式合并要求目标分支没有源分支之外的新提交，否则合并按钮不可用。项目设置里可开启"合并前自动变基"，源分支落后时由平台在合并时自动完成变基；频繁变基的半线性工作流还可以选择变基时不运行流水线，省下重复构建的算力。

• 压缩合并与长期分支冲突。在压缩合并后继续往同一个长期源分支提交，后续合并请求会显示"之前已合并的提交"并警告源分支落后——因为压缩产生的是虚拟副本，原始提交并不在目标分支上。长期运行的分支慎配压缩。

• 压缩与合并提交可能叠加。默认策略下即便压缩也会创建单独的合并提交，导致压缩提交和合并提交同时进主干。想只要一个提交，选快进 + 压缩的组合。

常见问题

问：改合并方式会影响已有历史吗？

答：不会。合并方法只约束之后的合并行为，既有提交图不会被重写，可随时按新策略继续。

问：哪种方式最适合做 CI 门禁的团队？

答：半线性历史。它把"目标分支在合并后也能构建成功"作为天然约束，与合并列车等进阶特性配合时主干稳定性最好。

问：快进式合并会不会丢信息？

答：不丢代码，只丢拓扑。分支的评审记录、流水线记录都留在合并请求页面，提交历史里少了合并节点而已。

小结

合并方式是三行设置换长期收益的典型决策：默认合并提交省心但历史最厚；半线性换主干可构建；快进换线性历史；压缩换回滚粒度。按团队的回滚习惯和定位工具链选一档，用 API 固化到所有新项目，比每次争论"要不要 rebase"划算得多。

下一步：在极狐GitLab 项目设置中核对合并方法与压缩行为，或在 官方文档 查看三种方式的提交图示例，选一档适合团队的策略再全量推广。