Squash and merge

Squash and merge

版本历史

使用 squash 和 merge,您可以将所有合并请求的提交合并为一个并保留干净的历史记录.

通过压接,您可以在接受合并请求时整理分支的提交历史记录. 它将合并请求中的所有更改作为单个提交应用,然后使用为项目设置的合并方法合并该提交.

换句话说,挤压合并请求会变成一长串提交:

合并为单个提交:

A squashed commit followed by a merge commit

压缩的提交的提交消息将是:

  • 取自合并中的第一条多行提交消息.
  • 如果找不到多行提交消息,则合并请求的标题.

注意:仅在至少 2 次提交时,此选项才生效. 由于没有什么可压缩的,因此如果只有 1 次提交,则提交消息不会更改.

注意:在此示例中,压缩的提交之后是合并提交,因为此示例存储库的合并方法使用了合并提交.

压缩也适用于快进合并策略,有关更多详细信息,请参见压缩和快进合并 .

Use cases

在功能分支上工作时,有时您想提交当前进度,但实际上并不关心提交消息. 这些”进行中的提交”不一定包含重要的信息,因此,您宁愿不将其包含在目标分支中.

使用 squash 和 merge,当准备好要合并的合并请求时,您要做的就是在按下 merge 之前将挤压启用,以将合并请求中的提交加入到单个提交中.

这样,您的基本分支的历史记录将保留有意义的提交消息,并且:

  • 如有必要, 还原更为简单.
  • 合并的分支将保留完整的提交历史记录.

可以创建或编辑合并请求的任何人都可以选择将其压缩在合并请求表单上:

然后可以在接受合并请求时覆盖它:

Commit metadata for squashed commits

压缩的提交具有以下元数据:

  • 消息:壁球提交消息或自定义消息.
  • 作者:合并请求的作者.

当项目了快进合并设置时 ,合并请求必须能够不压缩而进行快速转发以进行压缩. 这是因为压缩仅在接受合并请求时可用,因此即使挤压本身可以被认为等同于重新基准化,也可能需要在压缩之前对合并请求进行重新基准化.

Squash Commits Options

版本历史

  • 在 GitLab 13.2 中引入 .
  • 它部署在功能标记后面,默认情况下处于禁用状态.
  • 在 GitLab.com 上已禁用.
  • 不建议将其用于生产.
  • 要在 GitLab 自管实例中使用它,请让 GitLab 管理员 .

使用 Squash Commits Options,您可以为项目配置 Squash 和 Merge 的行为. 要进行设置,请导航至项目的设置>常规,然后展开合并请求 . 您将找到以下选项可供选择,这将影响提交给您的项目的现有和新合并请求:

  • 不允许 :用户不能在合并之前立即使用 Squash 和 Merge 来压缩所有提交. 启用或禁用它的复选框将被取消选中,并且对用户隐藏.
  • Allow: users will have the option to enable Squash and Merge on a merge request basis. The checkbox will be unchecked (disabled) by default, but and the user is allowed to enable it.
  • 鼓励 :用户可以选择在合并请求的基础上启用 Squash 和 Merge. 默认情况下会选中(启用)该复选框以鼓励使用,但允许用户禁用它.
  • 要求 :对所有合并请求都启用了”挤压和合并”,因此将始终执行. 启用或禁用它的复选框将被选中并向用户隐藏.

创建合并请求以及编辑现有请求的描述时,将显示” Squash and Merge”复选框,但” Squash Commit Options”设置为“不允许”或” Require”时除外.

注意:如果您的项目设置为“不允许挤压和合并”,则用户仍然可以选择通过命令行在本地挤压提交,并在合并之前强制将其推送到其远程分支.

壁球提交选项正在开发中,尚未准备好用于生产. 它部署在默认情况下禁用的功能标志的后面. 有权访问 GitLab Rails 控制台的 GitLab 管理员可以为您的实例启用它. 可以根据项目启用或禁用壁球提交选项.

要启用它:

禁用它: