【发布时间】:2020-01-17 10:06:49
【问题描述】:
我们遵循基于主干的开发方法,当一个功能准备就绪时,我们将其合并到 master 并创建具有语义版本的发布分支,因此我们可以完全控制主要/次要/补丁版本控制,
例如:
发布/1.0.0 .
发布/1.0.1 等 ..
我们在构建步骤中运行 gitversion,它考虑分支名称中提供的版本控制并基于它创建版本(默认 gitversion 行为),然后我们传播到我们的较低系统 我们仅在此版本成功部署到生产环境后才对其进行标记(我们的 ci/cd 工作流程的最后阶段)
我现在看到的问题是当樱桃挑选错误修复并合并到尚未标记的发布分支时。 (典型的基于主干的方法)
我正在寻找的行为如下:
假设 release/1.0.0 (当前标记的发布分支) ,gitversion - appname-1.0.0-rc.1 。
一个错误修复合并到 master
- 从 master 中挑选 bug 修复提交,合并到 release/1.0.0
- gitversion 将补丁值改为 appname-1.0.0-rc.2
- 发布/1.0.0 分支上的新提交
- gitversion 将补丁值改为 appname-1.0.0-rc.3
相反,我看到了以下行为:
- 从 master 中挑选 bug 修复提交,合并到 release/1.0.0
- gitversion 不增加补丁值,语义版本保持在 appname-1.0.0-rc.1
- 发布/1.0.0 分支上的新提交
- 语义版本保持在 appname-1.0.0-rc.1
这是我正在使用的配置 GitVersion.txt
【问题讨论】:
-
没有简单的图表很难理解。你能用一个例子添加一个 git 树图吗?
-
我也对这种行为感到困惑。目前尚不清楚如何在没有明确标记的情况下增加发布分支上的补丁。如果在
ContinuousDeployment模式下,我本来希望这会得到支持,但事实并非如此。你找到解决办法了吗?
标签: branching-strategy gitversion