在流程方面，与“标准流程”相比，您只需要一个可选步骤：如果您发现错误（或可能是严重错误），则回滚所有更改（即包含错误的合并）。
下面是它的工作原理：
从开发分支创建一个被测分支，或简称为 BUT
功能分支合并到测试分支中，而不是直接合并到开发分支中
你有一个 BUT，它现在要么与上一个版本相同，要么在此过程的最后一次迭代中经过良好测试。
现在您合并该分支中已准备好的所有功能分支/错误修复。
你测试它。如果出现关键问题，即使包含错误的功能/错误修复在下一个版本中不受欢迎，您可以通过重置和重做所有合并或通过变基和删除提交来撤消该功能的合并，这基本上是相同。请注意，这会更改分支的历史记录，因此在测试完成之前，任何人都不应将此分支合并到任何内容中。
如果测试迭代成功完成（即没有重大错误），您将其合并到开发中。
让我们检查一下这如何满足您的要求：
我们可以在不引入官僚主义的情况下进行部署（例如在每个月的最后一个星期五发布）。
您仍然像以前一样拥有发布分支。这里没问题。唯一的开销是您可能必须撤消合并，如果它们是错误的，但我没有看到解决方法。
如果某人提交了引入错误的代码，它不会影响其他已提交无错误代码的人。换句话说，如果程序员 A 试图通过引入一个新错误来修复错误，而程序员 B 已经修复了他的错误，那么程序员 B 的代码将进一步进入管道，而程序员 A 将延迟修复错误
查看
我们不能拥有无限的测试环境。我们也不想花一天时间设置测试环境。我们需要一个可以解决此要求的解决方案（因此，除非我遗漏了什么，否则不能选择对功能分支进行测试）
您只需要一个测试环境。更多可能有助于促进多个测试人员的并行工作。但这是可选的。
测试人员毫无疑问地确切地知道他们正在批准什么进入产品。
如果功能分支是 BUT 历史的一部分，您可以使用标准 git 命令非常轻松地确定，这正是您所需要的。
缺点/你需要的东西
只要未经测试人员的批准，就没有任何东西可以投入生产，也不能与其他人的工作合并。这可能会成为流程中的瓶颈，特别是如果来自功能分支的东西质量低下。如果测试人员必须取消合并内容，他们将不得不重新测试其余的内容（至少我认识的测试人员会坚持这样做，并且有充分的理由）。所以错误会减慢你的速度（这不是新的，但在这样的过程中变得非常明显）。
为了限制这种影响，您应该付出很多努力使功能分支尽可能好：
- 在与 BUT 合并之前运行功能分支的自动测试
- 与 BUT 合并后运行功能分支的自动测试
- 有很多好的自动化测试。
- 代码审查
- 结对编程
- 在您的测试环境中自动化部署
基本上，减少测试人员必须做的工作量并加快其余工作的一切都会有很大帮助。
你说你不能有很多测试环境。考虑您是否可以拥有部分测试环境，这些环境不需要所有资源，但仍然适合某些测试。