GitVersion中hotfix分支版本号异常及热修复正确处理方式咨询

版本号计算不符合预期的核心原因是分支命名未匹配GitVersion的hotfix分支规则：

• 从你贴的配置看，仅声明了develop/main/hotfix三类分支的运行模式，GitVersion默认对hotfix分支的匹配规则为分支名以hotfix/或hotfix-开头，只有命中规则的分支才会被识别为生产补丁分支，基于当前生产标签计算补丁位版本。
• 你创建的分支为fix/1.1，未命中hotfix分支匹配规则，会被GitVersion判定为普通特性分支，此时会拉取整个提交树里的最高版本基线——由于develop分支已经存在1.2.0-alpha.1的版本标记，最终就生成了1.2.0段的预发布版本号。

针对1.1.0生产版本的紧急修复，按以下流程操作即可得到预期的版本号：

1. 从已打1.1.0标签的master分支切补丁分支，必须使用hotfix/前缀，例如执行git checkout -b hotfix/1.1.1，此时在分支上提交代码后，GitVersion会自动生成1.1.1-hotfix-xxx格式的预发布版本号，不会跳到1.2.0版本段。
2. 补丁验证通过后，将hotfix/1.1.1分支合并回master分支，在master分支的合并提交上打1.1.1的正式版本标签，此时master分支上GitVersion计算出的正式版本即为1.1.1。
3. 必须将hotfix分支的改动反向合并回develop分支，避免后续版本发布时丢失本次补丁的改动，合并后develop分支的版本会自动在1.2.0-alpha的基线上顺延，不会出现版本冲突。

你之前写的合并打标签流程逻辑是对的，唯一问题是前期创建修复分支时用了fix/前缀导致分支识别错误。如果团队习惯用fix/作为补丁分支前缀，可以修改GitVersion配置扩展hotfix分支的匹配规则，示例配置如下：

branches:
  develop:
    mode: ContinuousDeployment
  main:
    mode: ContinuousDelivery
  hotfix:
    mode: ContinuousDelivery
    regex: ^(hotfix|fix)[/-]

修改后fix/开头的分支也会被正确识别为hotfix补丁分支。

是否走hotfix流程完全取决于修复的上线要求：

• 如果是需要紧急上线、跳过正常迭代周期的线上生产问题修复，走上述hotfix流程即可，不需要走develop/release的标准发布流程。
• 如果修复不需要紧急上线，属于后续1.2.0版本迭代计划内的内容，直接把改动提交到develop分支，跟着后续release/1.2.0分支走标准发布流程即可，不需要单独切hotfix分支。

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