合并请求工作流

GitLab 合并请求通常遵循以下流程之一：

• 在单个仓库中使用 受保护分支。
• 使用权威项目的 fork。

受保护分支流程

在受保护分支流程中，每个人都在同一个 GitLab 项目中工作，而不是使用 fork。

项目维护者获得 Maintainer 角色，普通开发者获得 Developer 角色。

维护者将权威分支标记为 ‘受保护’。

开发者将功能分支推送到项目，并创建合并请求，以便他们的功能分支被审查并合并到其中一个受保护分支中。

默认情况下，只有拥有 Maintainer 角色的用户才能将更改合并到受保护分支中。

• 优点：
  • 更少的项目意味着更少的混乱。
  • 开发者只需要考虑一个远程仓库。
• 缺点：
  • 每个新项目都需要手动设置受保护分支

设置受保护分支流程：

1. 首先确保你的默认分支通过 默认分支保护 受到保护。

2. 如果你的团队有多个分支，并且你希望管理谁可以合并更改，以及谁明确拥有推送或强制推送的选项，考虑将这些分支设置为受保护：

   • 管理和保护分支
   • 受保护分支

3. 对代码的每次更改都作为提交通过。你可以通过推送规则指定格式和安全措施，例如要求对进入代码库的更改进行 SSH 密钥签名：

   • 推送规则

4. 为了确保代码被团队中合适的人审查和检查，使用：

   • 代码所有者
   • 合并请求审批规则

旗舰版（Ultimate tier）中也可使用：

• 状态检查
• 安全审批

Fork 工作流

在 fork 工作流中，维护者在权威仓库中获得 Maintainer 角色，普通开发者获得 Reporter 角色，这禁止他们向其推送任何更改。

开发者创建权威项目的 fork，并将他们的功能分支推送到自己的 fork 中。

要将他们的更改合并到默认分支，他们需要创建一个跨 fork 的合并请求。

• 优点：
  • 在适当配置的 GitLab 组中，新项目会自动获得普通开发者的所需访问限制：为新项目配置授权的步骤更少。
• 缺点：
  • 项目需要保持其 fork 的更新，这需要更高级的 Git 技能（管理多个远程仓库）。