在Azure Pipelines中基于GitHub Flow配置GitVersion版本递增异常排查

问题场景 #

采用类GitHub Flow分支策略，发布分支为master，流程如下：

• master分支初始版本为1.2.0
• 从master拉取feature-NewFeature特性分支
• 特性分支提交新功能，提交信息附带+semver:minor
• 特性分支提交bug修复，提交信息附带+semver:patch
• 推送分支至Azure DevOps仓库并完成测试
• 测试通过后创建PR合并至master

预期合并后master版本应更新至1.4.0，但GitVersion输出始终停留在1.3.0，尝试过GitHubFlow/v1、Mainline模式配置及Rebase合并方式均未解决。

核心解决方案 #

1. 配置正确的GitVersion分支规则 #

采用Mainline模式并明确分支行为，GitVersion.yml示例配置：

mode: Mainline
branches:
  master:
    mode: ContinuousDeployment
    increment: None
    prevent-increment-of-merged-branch-version: true
    track-merge-target: true
  feature:
    mode: ContinuousDeployment
    tag: alpha
    increment: Minor
    track-merge-target: true

• prevent-increment-of-merged-branch-version: true：确保合并特性分支时，不会忽略分支内的semver递增指令
• track-merge-target: true：让特性分支基于master的版本基线计算版本

2. 确保合并时保留semver指令 #

Azure DevOps默认PR合并会生成新的合并提交，原始特性分支的提交信息无法被GitVersion识别，需调整合并方式：

• 使用Squash合并，并在squash后的提交信息中添加+semver:minor（minor优先级高于patch，一次合并只需保留最高级的递增指令即可达到1.4.0的预期）
• 若允许，直接采用Fast-forward合并，保留特性分支的所有提交，确保semver指令被GitVersion读取

3. 拉取完整的Git提交历史 #

Azure Pipelines默认拉取代码的深度有限，会导致GitVersion无法完整分析提交链。在GitVersion任务前执行：

git fetch --unshallow

或者在checkout步骤中配置全量拉取：

steps:
- checkout: self
  fetchDepth: 0

4. 验证版本计算逻辑 #

在管道中添加命令查看GitVersion的配置和计算日志，定位问题：

gitversion /showconfig
gitversion /output buildserver

通过日志确认semver指令是否被正确识别，以及版本基线是否基于master的1.2.0计算。

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