1

我们遵循基于主干的开发方法，当一个特性准备好时，我们将它合并到 master 并创建带有语义版本的发布分支，因此我们可以完全控制主要/次要/补丁版本，
例如：
release/1.0.0。
发布/1.0.1 等..

我们在构建步骤中运行 gitversion，它考虑分支名称中提供的版本控制并基于它创建版本（默认 gitversion 行为），然后我们传播到我们的较低系统我们仅在此版本成功部署到生产时标记此版本（最后阶段我们的 ci/cd 工作流程）

我现在看到的问题是当樱桃挑选错误修复并合并到尚未标记的发布分支时。（典型的基于主干的方法）

我正在寻找的行为如下：

假设 release/1.0.0 (当前标记的发布分支) ,gitversion - appname-1.0.0-rc.1 。在将错误修复合并到 master 后
- 从 master 提交樱桃选择错误修复提交，合并到 release/1.0.0
- gitversion 将补丁值添加到 appname-1.0.0-rc.2
- 在 release/1.0.0 分支上新提交
- gitversion 将补丁值改为 appname-1.0.0-rc.3

相反，我看到了以下行为：
- 从 master 提交的cherry-pick bug 修复提交，合并到 release/1.0.0
- gitversion 不增加补丁值，语义版本保持在 appname-1.0.0-rc.1
- 新在 release/1.0.0 分支上提交
- 语义版本保持在 appname-1.0.0-rc.1

这是我使用 GitVersion.txt的配置

4

1 回答 1

-1

GitVersion 有一个用于确定计算版本的层次结构，所有这些都由各种默认分支配置定义，可以通过执行GitVersion /showConfiguration.

您似乎需要根据团队的工作流程和分支模型自定义配置，以实现所需的行为。

于 2020-03-10T14:46:43.627 回答