如何解决在主线模式下使用拉取请求的 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 了解更多详情。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。