合并方法

Tier: 基础版, 专业版, 旗舰版
Offering: JihuLab.com, 私有化部署

极狐GitLab 中为项目选择的合并方法决定了如何将合并请求中的更改合并到现有分支中。

本页中的示例假设有一个包含提交 A、C 和 E 的 main 分支，以及一个包含提交 B 和 D 的 feature 分支：


Rendering chart...

配置项目的合并方法#

在左侧边栏中，选择 搜索或前往 并找到你的项目。
选择 设置 > 合并请求。
从以下选项中选择你想要的 合并方法：
- 合并提交
- 带半线性历史的合并提交
- 快进合并
在 合并时压缩提交 中，选择处理提交的默认行为：
- 不允许：从不执行 squash，且用户不能更改此行为。
- 允许：默认不执行 squash，但用户可以更改此行为。
- 鼓励：默认执行 squash，但用户可以更改此行为。
- 强制：始终执行 squash，且用户不能更改此行为。
选择 保存更改。

合并提交#

默认情况下，当分支合并到 main 时，极狐GitLab 会创建一个合并提交。无论提交是否在合并时进行 squash，都会创建一个单独的合并提交。此策略可能导致在 main 分支中添加一个 squash 提交和一个合并提交。

这些图展示了如果使用 合并提交 策略，feature 分支如何合并到 main 中。它们等同于命令 git merge --no-ff <feature>，以及在极狐GitLab UI 中选择 Merge commit 作为 合并方法：

使用 合并提交 方法合并特性分支后，main 分支看起来如下：
```
Rendering chart...
```
相比之下，压缩合并 构造了一个 squash 提交，即 feature 分支上所有提交的虚拟副本。原始提交 (B 和 D) 保持不变在 feature 分支上，然后在 main 分支上创建合并提交以合并 squash 分支：
```
Rendering chart...
```

Squash 合并图等同于极狐GitLab UI 中的这些设置：

合并方法: Merge commit。
合并时压缩提交 应设置为以下选项之一：
- Require。
- 选择 Allow 或 Encourage，并且在合并请求中选择 squash。

Squash 合并图也等同于这些命令：

shell
1git checkout `git merge-base feature main`
2git merge --squash feature
3git commit --no-edit
4SOURCE_SHA=`git rev-parse HEAD`
5git checkout main
6git merge --no-ff $SOURCE_SHA

带有半线性历史的合并提交#

每次合并都会创建一个合并提交，但只有在可能进行快速前进合并时才合并分支。这确保了如果合并请求构建成功，目标分支构建在合并后也会成功。使用这种合并方法生成的提交图示例：


Rendering chart...

当你访问选择了 Merge commit with semi-linear history 方法的合并请求页面时，你只有在可能进行快速前进合并时才能接受。当不可能进行快速前进合并时，用户可以选择重新基于，见Rebasing in (semi-)linear merge methods。

此方法等同于 合并提交 方法中的相同 Git 命令。然而，如果你的源分支基于目标分支（例如 main）的过时版本，你必须重新基于你的源分支。此合并方法创建了一个更清晰的历史记录，同时仍然可以看到每个分支的起始和合并位置。

快速前进合并#

有时，工作流策略可能要求没有合并提交的干净提交历史。在这种情况下，快速前进合并是合适的。通过快速前进合并请求，你可以保留线性的 Git 历史，并且在不创建合并提交的情况下接受合并请求。使用这种合并方法生成的提交图示例：


Rendering chart...

此方法等同于：

对于常规合并，使用 git merge --ff <source-branch>。
对于 squash 合并，使用 git merge --squash <source-branch> 后接 git commit。

当启用快速前进合并（--ff-only）设置时，不会创建合并提交，所有合并都将快速前进。只有在分支可以快速前进时才允许合并。当不可能进行快速前进合并时，用户可以选择重新基于，见Rebasing in (semi-)linear merge methods。

当你访问选择了 Fast-forward merge 方法的合并请求页面时，你只有在可能进行快速前进合并时才能接受。

在（半）线性合并方法中重新基于#

在这些合并方法中，你只能在源分支与目标分支保持最新时合并：

带有半线性历史的合并提交。
快速前进合并。

如果无法进行快速前进合并但可以进行无冲突的重新基于，极狐GitLab 提供：

/rebase 快速操作。
在用户界面中选择 Rebase 的选项。

你必须在本地重新基于源分支，满足以下两个条件时才进行快速前进合并：

目标分支领先于源分支。
无法进行无冲突的重新基于。

即使 squash 本身可以被视为等同于重新基于，重新基于可能在 squash 之前是必需的。

无 CI/CD 流水线的重新基于#

History

在极狐GitLab 15.3 中更改为 GA。功能标志 rebase_without_ci_ui 被移除。

要在不触发 CI/CD 流水线的情况下重新基于合并请求的分支，请在合并请求报告部分中选择 Rebase without pipeline。

此选项：

当不可能进行快速前进合并但可以进行无冲突的重新基于时可用。
当启用 流水线必须成功 选项时不可用。

在需要频繁重新基于的半线性工作流项目中，无 CI/CD 流水线的重新基于可以节省资源。

Squash 和合并