实现分支合并限制
Azure DevOps 和 GitHub 托管的版本控制系统中的分支合并限制对于在软件开发项目中控制代码质量、促进协作和增强稳定性至关重要。 它们可帮助组织强制实施代码评审、验证自动测试的成功完成，并防止强制推送到指定的分支。 这些约束有助于维护代码库的完整性，防止意外更改，并确保仅将经过验证和批准的更改合并到生产分支中。
分支合并限制的一般概念与平台无关。 虽然其实现在 Azure DevOps 与 GitHub 之间稍有不同，但也有很多相似之处，在大多数情况下都在二者之间实现了功能奇偶一致性。
Azure DevOps
在 Azure DevOps 中，你可以使用基于分支保护的策略来实现分支合并限制。
若要实现分支保护，请在 Azure DevOps 门户中导航到存储库，然后选择要应用合并限制的分支。 或者，可以将保护范围限定为与指定模式匹配的当前和未来分支。 在保护配置中，你可以应用以下分支策略：
- 需要达到最低的评审者数量：确保在未达到所需的评审数量前无法合并更改。
- 检查链接的工作项：通过检查拉取请求上的链接项来鼓励实现可跟踪性
- 检查注释解决情况：验证是否已解决拉取请求上的所有注释
- 限制合并类型：通过限制完成拉取请求时可用的合并类型来控制分支历史记录。 这包括有选择地启用或禁用以下合并类型的选项：
- 基本合并(不快进)：完全按照开发过程中发生的情况保留历史记录。
- 变基和快进：通过在没有合并提交的情况下将源分支提交重播至目标，来创建线性历史记录。
- Squash 合并：通过将源分支提交压缩为目标分支上的单个新提交来创建线性历史记录。
- 通过合并提交变基：通过将源分支提交重播至目标并创建合并提交，来创建半线性历史记录。
另外，还可配置以下设置：
- 生成验证：通过预先合并和生成拉取请求更改来验证代码。
- 状态检查：要求其他服务发布成功状态以完成拉取请求。 状态检查是在拉取请求过程中触发的自动任务，用于在允许将拉取请求合并到目标分支之前验证某些条件。 在 Azure DevOps 中，状态检查与生成管道和发布管道相关联。
- 自动包括评审者：指定在拉取请求更改某些领域的代码时自动包含的代码评审者。
你还可以选择锁定分支，从而有效地将其设为只读。
请注意，Azure DevOps 提供了两个选项来绕过存储库的策略要求。 若要实现它们，需要通过将执行以下操作的权限设置为“允许”来更改存储库的默认安全配置：
- 完成拉取请求时绕过策略。
- 推送时绕过策略。
必须确保这些权限只授予指定人员，这些人员要能够理解这些操作对遵循组织标准的影响，并可以对其使用进行合理的判断。
GitHub
在 GitHub 中，你可以使用分支保护规则来实现分支合并限制。 分支保护规则定义协作者是否可以删除或强制推送到分支，并为任何分支推送设置要求，例如通过状态检查或具有线性提交历史记录。 与在 Azure DevOps 中一样，你可以根据名称模式匹配将它们应用到特定分支。
若要实现分支保护规则，请在 GitHub Web 界面中导航到你的存储库，在“设置”选项卡上的导航菜单中选择“分支”菜单项。 这样，就可以访问分支保护规则配置。 在保护配置中，你可以应用以下规则：
- 需要在合并前提交拉取请求：要求参与者在合并更改之前提交拉取请求以供评审和审批。
- 需要在合并之前通过状态检查：指定在允许合并之前必须通过的状态检查。 启用后，必须先将提交的内容推送到另一分支，然后进行合并，或者在通过状态检查后将其直接推送到与此规则匹配的某个分支。
- 需要在合并前解决对话：确保在合并拉取请求之前解决与代码更改相关的所有讨论和注释。
- 需要签名的提交：强制要求使用已验证的签名对推送到受保护分支的提交进行签名，从而增强安全性并确保代码贡献的真实性。
- 需要线性历史记录：阻止受保护分支中的合并提交，从而强制实施线性历史记录，这样便可以更轻松地跟踪和根据需要撤消任何更改。 这实际上意味着任何拉取请求都必须使用 Squash 合并或变基合并。
- 需要在合并之前部署成功：规定要先对拉取请求中建议的更改进行全面测试和验证，然后才能将其集成到代码库。
- 锁定分支：作为其 Azure Devops 等效项，限制对分支的写权限，使其成为只读分支。
- 不允许绕过上述设置：消除了管理员和被授予分支保护绕过权限的用户绕过其他规则的可能性。
- 允许强制推送：允许具有推送权限的用户强制推送更改。 与在 Azure DevOps 中一样，这只是一项紧急措施。
- 允许删除：允许具有推送权限的用户删除受保护分支。 虽然这种灵活性可以简化分支管理，但它也会带来意外或恶意删除分支的风险，因此应谨慎控制，以防止数据丢失并维护存储库完整性。