自定义Git策略的版本控制咨询：策略名称与版本规则建议

一、Git策略的标准名称 #

你当前的Git策略是Git Flow的定制变种，核心是「每个功能对应独立Release分支」，也可称为Feature-Centric Parallel Release Strategy（以功能为中心的并行发布策略）。
它结合了两种经典工作流的特点：

• 继承Git Flow的main/生产、develop、feature/release分支分层逻辑
• 区别于标准Git Flow「单Release分支整合所有Feature」的模式，改为「每个Feature单独创建Release分支」，完美适配多功能并行、发布顺序灵活的场景。

二、版本控制方案建议 #

针对你提到的镜像标签规范与测试一致性问题，给出以下落地方案：

1. 镜像标签双标签机制（核心解决生产镜像未测试问题） #

• 测试环境（实验室/QA）：使用带分支和提交信息的扩展标签，格式为：Major.Minor.Patch-<branch-name>-<short-commit-hash>
  示例：1.2.0-release/JIRA-123-abc123
  作用：唯一标识测试版本，关联代码分支和具体提交，方便问题回溯。
• 生产环境：当QA验证通过后，给同一镜像追加标准版本标签，格式为：vMajor.Minor.Patch
  示例：给已通过测试的1.2.0-release/JIRA-123-abc123镜像追加v1.2.0标签
  好处：生产使用的是完全经过测试的镜像，避免重新构建带来的一致性问题，同时保持生产版本标签的规范性。

2. 版本号提前约定规则 #

• 创建release分支时，就确定好该功能对应的Major.Minor.Patch版本号（可在JIRA工单中同步约定），避免后续版本混乱。
• 若同一release分支需要修复bug，递增Patch版本号：比如第一次发布候选是1.2.0，修复bug后改为1.2.1，对应镜像标签更新为1.2.1-release/JIRA-123-def456，QA通过后追加v1.2.1标签。

3. 分支合并后的版本同步 #

• release分支合并到main后，给main分支的对应提交打上与生产镜像一致的标准版本标签（如v1.2.0）。
• 将main分支的版本号更新（如代码中的版本配置文件）同步到develop分支，保证后续feature分支基于最新版本开发。

内容的提问来源于stack exchange，提问作者Anastasiia Melnyk