在基于主干的开发中，团队可以应用哪些控制来确保从测试/登台到生产的升级过程有严格的审批流程？
在 gitflow devops 中（其中有一个长期存在的不稳定分支，其中的更改会定期合并到稳定分支中，这样 CI/CD 就可以将不稳定分支部署到开发/暂存环境，并将稳定分支部署到生产环境）可以使用 BitBucket 或 GitHub 对稳定分支应用分支保护（例如在合并 PR 之前需要多次批准和通过测试），同时允许开发人员以更少的摩擦推送到不稳定分支（以提高试验节奏）基础设施代码通过实际部署进行更改）。然而，基于主干的工作流程已经越来越流行（其中升级过程只涉及标记头部，而不是尝试将精心挑选的提交移植到不同的历史记录中）。发布标记工作流程如何包含类似的保护（即多个审批者和通过测试），同时对其他未标记的推送/合并到该主干分支保持更宽松的态度？
例如，此类控件是否已明确提供功能（在 GitHub、BitBucket 或任何等效项中），或者是否可以仅通过适度的操作来支持（例如启用常规标签保护以及实施手动批准的 CI 操作来创建新标签） ，或者是否需要在特权服务帐户下运行外部工具/接口（相当于定制的代码管理平台）？
传统的答案可能是通过为每个功能分支启动（和关闭）单独的测试环境来避免这个问题，而不是维护一个永久的临时环境。在 DevOps 环境中，可能需要成熟/复杂的基础设施即代码 CI 来实现这一点，因此，渐进式交付通常由 Flagger 或 ArgoCD 等其他工具来管理，而不是严格的 GitOps。
没有“发布/标签请求”的既定概念。目前的平台似乎无法像拉取请求那样严格地促进协作发布标记工作流程。一些平台似乎有助于限制对某些主体的标记（有时将
refs/tags/**大多数平台确实支持不同分支的不同保护级别以及任意分支之间的 PR，因此在 GitOps 下管理单独的暂存与生产环境的明显方法仍然是维护稳定（或发布）分支，并且升级工作流程将主（或开发）分支合并到稳定分支的 PR。这个 gitflow 的主要缺陷是环境之间的意外漂移和困难的合并。为了避免漂移，重要的是环境之间任何预期的持久差异都使用单独的子目录表示，并且分支之间的差异在合并后决不允许持续存在。在实践中，可能需要 CI 脚本以确保这些分支最终完全同步的方式提出发布 PR。