问题描述
我有以下场景：
我们正在使用功能分支工作流和容器。
团队 A 的开发人员创建分支（从 master/main）来处理功能，一旦完成，代码将与发布分支合并。在发布分支上提交会启动一个管道来构建、运行测试并将容器部署到暂存环境。用户批准后，容器被“提升”为生产，开发人员将发布分支与主分支合并，创建标签并完成工作。
这很好用，除非我们需要修补程序。
当 A 团队的代码处于 staging 环境中时，B 团队开始在“hotfix”分支上工作，他们的提交也启动了一个管道来运行构建、测试、创建容器并部署到一个特殊的 staging 环境，我们称之为“修补程序阶段”。此时，我们有同一个项目的 2 个容器，正在验证不同的代码。
如果团队 A 的容器获得批准，则将其部署到生产环境中，但如果团队 B 的容器获得批准，则也将其部署到生产环境中。问题是团队 A 的容器将在没有修补程序的情况下投入生产，而团队 B 的容器没有团队 A 的功能。
团队 A 和团队 B 是不同的公司，每个公司都有自己的 SLA。他们不想将“hotfix”分支与“feature”分支（或“release”分支）合并。
有没有可以解决这个问题的 git 工作流程？
解决方法
在 git flow 中，功能分支应该从开发分支开始。
当需要发布时，会从开发中创建一个发布分支。 如果在发布阶段发现错误，则从发布分支创建修复分支，当错误解决时，修复分支必须合并到发布分支和开发分支（可以同时发展）。您可以针对在质量检查期间发现的所有错误执行此操作。
如果在以前的版本中发现错误，则必须从 main 启动一个修补程序分支并关闭到 develop。如果在那一刻有发布分支，您可以选择是否也发布热修复。
当事情看起来稳定时，会在发布分支上创建一个标签，这就是发布。您还可以使用候选发布标记，然后标记最终候选发布。
发布完成后，您可以关闭主分支的发布分支，在此期间开发可以发展并获得错误修复