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

Question

我正在尝试为 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

所有版本增量都运行良好，期待拉取请求完成。拉取请求获得与功能分支相同的版本，但是当它合并到主分支时，主版本会根据拉取请求的提交量增加。

一个例子：

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 工具按预期工作。

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

Answer 1

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

如果您使用“rebase and fast-forward”合并类型。拉取请求内容中的第一次提交获得了预期的版本，而所有后续提交都随着默认补丁增量而增加。

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

有关详细信息，请参阅：Complete the pull request。