2

我正在使用带有 Mainline 模式的 GitVersion。使用默认设置，它会随着 master 中的每次提交增加补丁号。有没有办法在每次推送而不是每次提交时增加补丁数量？

如果我将 3 次提交一起推送，补丁会增加 3。在这种情况下，我会在 VSTS 构建中获得从 2.0.4 到 2.0.7 的版本跳转。

GitVersion.yml

mode: Mainline

注意：我只有一个分支，即“master”，我将继续将我的更改直接推送到 master。我还不打算使用任何分支策略。

4

2 回答 2

2

在我看来，您有两种选择。

您可以覆盖increment: None您的master分支配置：

branches:
  master:
    increment: None

但是，我认为您总是需要通过 git 提交“手动”更改代码版本，例如包含在您的提交消息中：+semver: (major|minor|patch)，或更新您的GitVersion.yml文件以设置next-version配置。我认为，这完全抵消了使用 GitVersion 的许多好处。但是，这仍然比完全没有版本控制要好！

但是，说你在做“主线”开发，并不一定意味着你只在 master 分支中开发。我相信主线开发主要意味着您从 master 分支中释放（即您没有使用带有两个长期存在的分支的 GitFlowmaster和develop），并且master任何时间点的状态都可以部署到生产中。

因此，正如@prestonsmith在他的回答中已经说过的那样，您可以使用两个不同的分支来实现您正在寻找的东西。您和您的团队可以在 master 的短期主题分支中工作，并最终合并（正常的合并提交以保留历史记录，或 squash 合并（丢失分支历史记录，只需将单个提交引入 master 并创建所有更改）主题分支）。这将导致单个补丁版本增量的默认行为，稍后可以通过使用 git 标签将其更改为次要或主要增量，或者在您的合并提交消息中添加类似的内容+semver: (major|minor)来代替增量主要或次要版本号。

于 2020-03-10T15:54:45.263 回答
1

简短的回答是不 - 抱歉:(

然而，如果你决定只使用两个分支，你可以通过使用 Git 的“Squash and Merge”策略来模拟它来实现它。基本上，合并后，您的所有提交都将成为主分支（主分支）上的单个提交。

感觉很简单，可以将其作为建议:)

于 2018-11-12T20:59:08.403 回答