实施分支合并限制

Azure DevOps 和 GitHub 托管的版本控制系统中的分支合并限制对于控制代码质量、促进协作和增强软件开发项目中的稳定性至关重要。 它们可帮助组织强制实施代码评审、验证自动测试的成功完成，并防止强制推送到指定的分支。 这些约束有助于维护代码库的完整性，防止意外更改，并确保仅验证和批准的更改合并到生产分支中。

分支合并限制的一般概念与平台无关。 虽然 Azure DevOps 和 GitHub 的实现方式略有不同，但它们也有很多相似之处，因此在大多数情况下，这两个平台的功能是相当的。

Azure DevOps

在 Azure DevOps 中，可以使用基于分支保护的策略来实现分支合并限制。

若要实现分支保护，请在 Azure DevOps 门户中导航到存储库，然后选择要向其应用合并限制的分支。 或者，可以将保护范围限定为与指定模式匹配的当前和将来分支。 作为保护配置的一部分，可以应用以下分支策略：

• 需要达到最低的评审者数量：确保在未达到所需的评审数量前无法合并更改。
• 检查链接的工作项：通过检查拉取请求上的链接项来鼓励实现可跟踪性
• 检查评论解决： 验证拉取请求中的所有评论是否已解决
• 限制合并类型： 通过在完成拉取请求时限制可用的合并类型来控制分支历史记录。 这包括有选择地启用或禁用以下合并类型的选项：
  • 基本合并(不快进)：完全按照开发过程中发生的情况保留历史记录。
  • 变基和快进：通过在没有合并提交的情况下将源分支提交重播至目标，来创建线性历史记录。
  • Squash merge： 通过将源分支提交精简为目标分支上的单个新提交来创建线性历史记录。
  • 通过合并提交变基：通过将源分支提交重播至目标并创建合并提交，来创建半线性历史记录。

（可选）可以配置以下约束：

• 生成验证：通过预先合并和生成拉取请求更改来验证代码。
• 状态检查： 要求其他服务发布成功状态才能完成拉取请求。 状态检查是在拉取请求过程中触发的自动任务，用于在允许将拉取请求合并到目标分支之前验证某些条件。 在 Azure DevOps 中，状态检查与生成管道和发布管道相关联。
• 自动添加审阅者： 指定代码审阅者，以便在拉取请求更改特定代码区域时自动纳入。

你还可以选择锁定分支，从而有效地将其设为只读。

请注意，Azure DevOps 提供了两个选项来绕过存储库的策略要求。 若要实施这些更改，您需通过将权限设置为“允许”来更改存储库的默认安全配置，以执行以下操作：

• 在完成拉取请求时，可以绕过策略规定。
• 推送时绕过策略。

必须确保这些权限仅授予那些能够理解这些行为对遵守组织标准的影响并且能够对其使用进行合理判断的指定人员。

GitHub

在 GitHub 中，可以使用分支保护规则实现分支合并限制。 分支保护规则定义协作者是否可以删除或强制推送到分支，并为任何分支推送设置要求，例如通过状态检查或具有线性提交历史记录。 与 Azure DevOps 一样，可以根据名称模式匹配将它们应用到特定分支。

若要实现分支保护规则，请导航到 GitHub Web 界面中的存储库，在“设置”选项卡上，并在导航中，选择“分支”菜单项。 这样，就可以访问 Branch Protection 规则配置。 作为保护配置的一部分，可以应用以下规则：

• 在合并之前需要拉取请求： 要求参与者在合并更改之前提交拉取请求以供评审和审批。
• 要求在合并之前通过状态检查： 指定在允许合并之前必须通过的状态检查。 启用后，必须先将提交推送到另一个分支，然后在状态检查通过后直接合并或推送到与此规则匹配的分支。
• 需要在合并前解决对话：确保在合并拉取请求之前解决与代码更改相关的所有讨论和注释。
• 需要签名提交： 授权将推送到受保护分支的提交使用已验证的签名进行签名，增强安全性，并确保代码贡献的真实性。
• 需要线性历史记录： 防止受保护分支中的合并提交，强制实施线性历史记录，从而更轻松地跟踪和根据需要撤消任何更改。 这实际上意味着任何拉取请求都必须使用 Squash 合并或变基合并。
• 在合并之前，需要部署才能成功： 规定在集成到代码库之前，在拉取请求中提出的更改经过全面测试和验证。
• 锁定分支： 作为其 Azure Devops 等效项，限制对分支的写入访问权限，使其成为只读的。
• 不允许绕过上述设置： 阻止了其他规则被拥有绕过分支保护权限的管理员和用户绕过的可能性。
• 允许强制推送： 允许具有推送权限的用户强制更改。 与 Azure DevOps 一样，这只是一项紧急措施。
• 允许删除： 允许用户使用推送权限删除受保护的分支。 虽然这种灵活性可以简化分支管理，但它也带来了意外或恶意的分支删除的风险，应谨慎控制，以防止数据丢失和维护存储库完整性。