自定义 Git 策略中的版本控制方法

Question

概述： 这是我的 git 策略：

• 主要分支反映生产
• 开发人员使用 feature/jiraTiketNb 从 main 创建分支并在那里实现它
• 开发人员可以合并任何时间功能/jiraTiketNb 以开发分支并将其部署到实验室环境
• develop 分支不稳定，可以随时删除并从 main 重新创建
• 当功能准备就绪时，开发人员从 main 创建一个 release/jiraTiketNb 分支，并从 feature/jiraTiketNb 做 PR
• PR 合并到 release/jiraTiketNb 后，程序可以部署到 QA env
• 如果发现错误，将创建另一个 PR 以发布/jiraTiketNb 并重新部署应用程序
• 在 QA 验证应用程序可以从发布/jiraTiketNb 分支部署到生产后
• 然后我们合并到main并添加带有版本号的标签

你知道这个 git 策略的名字吗？也许它已经存在了。

用途： 该策略试图涵盖我们同时开发许多功能并且不知道部署顺序的情况。两个独立的功能可能会一起发布或一个接一个发布。

对于每个部署，我们创建一个带有与应用程序版本对应的标签的 docker 镜像。应该有可能在每个部署之间进行回滚，所以版本应该是唯一的。

问题： 你能建议版本控制的可能方法吗？

我尝试设置 git version 来为发布分支执行版本控制，例如：Major.Minor.Patch-branchName-revisionNm。示例：1.2.0.-release/jiraTiketNb-2。不确定是否可以？实际上，对于 QA 环境，这并不重要。但对于产品来说，它可能看起来很奇怪。我想在 QA 之后为 prod 创建另一个 docker 镜像，并将其部署到 prod，更新版本类似于 1.2.0，但它不会测试 docker 镜像，所以我不确定它是否正确。