在主线模式下使用拉取请求的 Azure DevOps GitVersion 行为

问题描述

我正在尝试为 NuGet 包的 .NET Standard 库项目设置 DevOps 管道。我正在使用 GitVersion 来跟踪包的语义版本。我使用 VSBuild@1 任务进行构建，因此我只包含 GitVersion 作为 GitVersion.MsBuild 包。

我的目标是使用一个简单的 GitHubFlow 作为工作流程，因此我将 GitVersion 配置为主线模式。我只使用功能和修补程序分支，并且只想通过拉取请求将所有功能分支合并到 master。我使用的GitVersion配置是这样的：

mode: Mainline
branches:
  master:
    regex: ^master$|^main$
    tag: ''
    prevent-increment-of-merged-branch-version: true
    track-merge-target: false
    tracks-release-branches: false
    is-release-branch: false
    is-mainline: true
    is-source-branch-for: ['feature','hotfix']
  feature:
    tag: useBranchName
  hotfix:
    tag: useBranchName
  pull-request:
    tag: rc

所有版本增量都运行良好，期待拉取请求完成。 Pull reguest 获得与 feature 分支相同的版本，但是当它合并到 master 时，master 版本会增加提交 pull request 的数量。

示例：

master is on version 1.2.0
  new feature branch 'feature/myfea' gets version 1.2.1-myfea
    commit on feature with message +semver: minor
  feature branch is on version 1.3.0-myfea
  new pull request from feature to master gets version 1.3.0-rc
    commit
    commit
  feature branch is on version 1.3.0-myfea
  pull request in on version 1.3.0-rc
    complete pull request
master is on version 1.3.2

为什么会这样？有没有办法让 master 设置与 pull request 相同的版本，比如上面例子中的 1.3.0？

--- 编辑---

这是最常见的情况 - 至少对我而言，结果证明这是用户错误。 GitVersion 工具按预期工作。

在将 pull request 合并到 master 时，我使用了“rebase and fast-forward”合并类型。这自然会导致观察到的行为。拉取请求内容中的第一个提交获得了预期的版本，而所有后续提交都以默认补丁增量递增。我将合并类型更改为“squash merge”，瞧，主分支版本控制就像我想要的那样工作。

解决方法

我看到Yuhis更新了问题描述，所以这个问题是由于在将pull request合并到master时选择了不正确的合并策略造成的。

如果您使用“变基和快进”合并类型。拉取请求内容中的第一次提交获得了预期的版本，而所有后续提交都以默认补丁增量递增。

如果您将合并类型更改为“squash merge”，然后主分支版本控制按预期工作。

请参阅：Complete the pull request 了解更多详情。