我有以下场景：
我们正在使用一个功能分支工作流和容器。
Team A的开发人员创建分支(从master/main(来处理特性，一旦完成，代码就会与发布分支合并。发布分支上的Commits启动一个管道来构建、运行测试并将容器部署到临时环境。在用户批准之后；被提升"；到生产阶段，开发人员将发布分支与主分支合并，创建标记并完成工作。
这很好用，除非我们需要修补程序。
当团队A的代码处于暂存环境中时；修补程序"；分支，以及它们的提交还启动了一个管道，该管道运行构建、测试、创建容器并部署到一个特殊的暂存环境中，让我们称之为"；热修复阶段"；。在这一点上，我们有两个相同项目的容器，不同的代码正在验证中。
如果团队A的容器获得批准，它将部署到生产环境中，但如果团队B的容器获得了批准，它也将部署到产品环境中。问题是，团队A的容器将在没有修补程序的情况下投入生产，而团队B的容器没有团队A的功能。
团队A和团队B是不同的公司，每个公司都有自己的SLA。他们不想合并"；修补程序"；用"；特征"；分支(或"释放"分支(。
有没有一个git工作流可以解决这个问题？
在git流中，功能分支应该从开发分支开始。
到了发布的时候，就会从开发中创建一个发布分支。如果在发布过程中发现错误，则从发布分支创建修复分支，当错误得到解决时，修复分支必须合并到发布分支和开发分支中(在此期间可以发展(。你可以对qa.中发现的所有错误都这样做
如果在以前的版本中发现了一个bug，那么必须从main启动一个修补程序分支，然后关闭以进行开发。如果此时有发布分支，您可以选择是否也要发布热修复程序。
当事情看起来稳定时，就会在发布分支上创建一个标记，这就是发布。您也可以使用发布候选者标记，然后标记最终的发布候选者。
当发布完成后，您可以将发布分支关闭到main中，在此期间，开发可以进化并接收错误修复