如何使用gitversion修复bug后自动增加补丁版本

Reg*_*ggi 5 versioning git git-flow gitversion

概括

我正在建立一个新项目,并想使用 GitVersion 来计算我的应用程序的当前版本。我需要的是使用 MAJOR.MINOR.PATCH 进行语义版本控制,其中 MAJOR 和 MINOR 随着发布分支名称的增加而增加,而 PATCH 在每个错误修复或修补程序合并时都会增加。

目前我正在尝试将 GitFlow 实施到我的分支策略中,但我会向您解释我正在做的事情。

  1. 所有开发都在开发分支上完成(创建一个feature/*分支并合并回开发分支)。
  2. 当我想创建一个版本时,我从开发创建一个releases/[version]分支
  3. 当我在发行版中发现错误时,我会创建一个bugfix/*分支,并在完成后将其合并回release/[version]
  4. 当没有发现更多错误时,releases/[version]将合并到 master 中并用正确的版本标记。

问题出在步骤 3 中。例如,当我使用releases/0.1.0时,GitVersion 在bugfix/*合并后不会增加 PATCH 版本。它只是停留在 0.1.0 而不是想要的 0.1.1。它确实增加了提交计数!

迄今为止采取的步骤

目前我正在使用以下 gitversion.yml 文件(请参阅下一个标题)。其中包括一个应该增加补丁的修补程序分支。由于某种原因,在我创建bugfix/*分支后,当您在 bugfix 分支上运行 GitVersion 时,它不会增加 PATCH,所以我认为我在这里遗漏了一些东西。

唯一有效的方法是在bugfix/*分支的最后一次提交上设置一个标签到新版本(0.1.1-test)。但由于 GitVersion 在 bugfix 分支上计算版本 0.1.0,我无法自动升级 PATCH 并在提交上添加所需的 0.1.1-test 标签。

我还认为,当您合并回发布分支时,GitVersion 会增加版本。但即使我将增量设置为“补丁”,这种情况也不会发生。所以在这里,我也想我错过了一些东西,或者我只是想要 GitVersion 不适合的东西。

gitversion.yml

assembly-versioning-scheme: MajorMinorPatch
mode: ContinuousDeployment
branches:
  develop:
    tag: ''
  feature:
    tag: ''
  release:
    tag: test
    increment: Patch
    tracks-release-branches: true
    source-branches:
    - develop
    - bugfix
  bugfix:
    tag: ''
    increment: Patch
    prevent-increment-of-merged-branch-version: false
    regex: bugfix(es)?[/-]
    source-branches:
    - release
ignore:
  sha: []
Run Code Online (Sandbox Code Playgroud)

预期结果

当我将bugfix/*分支合并回我的releases/[version]分支时,我希望增加 PATCH 。

例子:

7f8ef13 34 minutes ago  (HEAD -> releases/0.1.0) [3]
|\
| * 3363677 34 minutes ago  (bugfix/TE-01) [2]
|/
* ac22ccb 36 minutes ago  (tag: 0.1.0-test, master, develop) [1]
Run Code Online (Sandbox Code Playgroud)

[1] 此时我创建了releases/0.1.0分支,因此GitVersion应该计算0.1.0(有效!)

[2] 这里版本并不重要,所以它可以保留 0.1.0-bug

[3] 此处版本需要增加到 0.1.1,因为我们进行了错误修复合并。(这没有发生!)。目前它仍然是 0.1.0,但它确实增加了提交计数。所以它会在 [1] 和 [3] 之间从 0.1.0-test.0 到 0.1.0-test.2。

也许我正在尝试做一些根本不可能的事情,我真的不知道。因此,如果有人有想法,请随时回复:)

我还知道 GitFlow 默认情况下没有错误修复分支。但我认为直接在发布分支上修复错误是一个奇怪的想法。尤其是当你在一个更大的团队中工作时。这就是我尝试创建错误修复流程的原因。

完整的 gitversion -diag 输出

C:\Testig gitversion>gitversion -diag
INFO [05/08/19 10:38:53:79] Dumping commit graph:
INFO [05/08/19 10:38:53:90] *   7f8ef13 49 minutes ago  (HEAD -> releases/0.1.0)
|\
| * 3363677 49 minutes ago  (bugfix/TE-01)
|/
* ac22ccb 50 minutes ago  (tag: 0.1.0-test, master, develop)

INFO [05/08/19 10:38:53:90] Working directory: C:\Testig gitversion
INFO [05/08/19 10:38:53:91] IsDynamicGitRepository: False
INFO [05/08/19 10:38:53:93] Returning Project Root from DotGitDirectory: C:\Testig gitversion\.git - C:\Testig gitversion
INFO [05/08/19 10:38:53:94] Running on Windows.
INFO [05/08/19 10:38:53:94] IsDynamicGitRepository: False
INFO [05/08/19 10:38:53:94] Returning Project Root from DotGitDirectory: C:\Testig gitversion\.git - C:\Testig gitversion
INFO [05/08/19 10:38:53:94] Project root is: C:\Testig gitversion
INFO [05/08/19 10:38:53:94] DotGit directory is: C:\Testig gitversion\.git
INFO [05/08/19 10:38:53:95] IsDynamicGitRepository: False
INFO [05/08/19 10:38:53:95] Returning Project Root from DotGitDirectory: C:\Testig gitversion\.git - C:\Testig gitversion
INFO [05/08/19 10:38:53:98] IsDynamicGitRepository: False
INFO [05/08/19 10:38:53:98] Returning Project Root from DotGitDirectory: C:\Testig gitversion\.git - C:\Testig gitversion
INFO [05/08/19 10:38:54:07] Using latest commit on specified branch
INFO [05/08/19 10:38:54:08] Running against branch: releases/0.1.0 (7f8ef13e5f43d3827d30a25f936424210cefb2c8)
INFO [05/08/19 10:38:54:09] Begin: Calculating base versions
  INFO [05/08/19 10:38:54:10] Fallback base version: 0.1.0 with commit count source ac22ccb4dd8937a5ec46ad1504281aee490b4411 (Incremented: None)
  INFO [05/08/19 10:38:54:15] Git tag '0.1.0-test': 0.1.0-test with commit count source ac22ccb4dd8937a5ec46ad1504281aee490b4411 (Incremented: 0.1.0-test)
  INFO [05/08/19 10:38:54:17] Begin: Finding branch source of 'releases/0.1.0'
    INFO [05/08/19 10:38:54:18] Begin: Finding merge base between 'releases/0.1.0' and 'develop'.
      INFO [05/08/19 10:38:54:19] Found merge base of ac22ccb4dd8937a5ec46ad1504281aee490b4411
      INFO [05/08/19 10:38:54:19] Merge base of releases/0.1.0' and 'develop is ac22ccb4dd8937a5ec46ad1504281aee490b4411
    INFO [05/08/19 10:38:54:19] End: Finding merge base between 'releases/0.1.0' and 'develop'. (Took: 5.00ms)
    INFO [05/08/19 10:38:54:19] Begin: Finding merge base between 'releases/0.1.0' and 'master'.
      INFO [05/08/19 10:38:54:19] Found merge base of ac22ccb4dd8937a5ec46ad1504281aee490b4411
      INFO [05/08/19 10:38:54:19] Merge base of releases/0.1.0' and 'master is ac22ccb4dd8937a5ec46ad1504281aee490b4411
    INFO [05/08/19 10:38:54:19] End: Finding merge base between 'releases/0.1.0' and 'master'. (Took: 0.96ms)
    INFO [05/08/19 10:38:54:19] Begin: Finding merge base between 'releases/0.1.0' and 'releases/0.1.0'.
      INFO [05/08/19 10:38:54:19] Found merge base of 7f8ef13e5f43d3827d30a25f936424210cefb2c8
      INFO [05/08/19 10:38:54:19] Merge base of releases/0.1.0' and 'releases/0.1.0 is 7f8ef13e5f43d3827d30a25f936424210cefb2c8
    INFO [05/08/19 10:38:54:19] End: Finding merge base between 'releases/0.1.0' and 'releases/0.1.0'. (Took: 1.00ms)
    INFO [05/08/19 10:38:54:20] Multiple source branches have been found, picking the first one (develop).
This may result in incorrect commit counting.
Options were:
 develop, master
  INFO [05/08/19 10:38:54:25] End: Finding branch source of 'releases/0.1.0' (Took: 85.80ms)
  INFO [05/08/19 10:38:54:33] Version in branch name: 0.1.0 with commit count source ac22ccb4dd8937a5ec46ad1504281aee490b4411 (Incremented: None)
  INFO [05/08/19 10:38:54:35] Begin: Finding merge base between 'releases/0.1.0' and 'releases/0.1.0'.
    INFO [05/08/19 10:38:54:38] Found merge base of 7f8ef13e5f43d3827d30a25f936424210cefb2c8
    INFO [05/08/19 10:38:54:42] Merge base of releases/0.1.0' and 'releases/0.1.0 is 7f8ef13e5f43d3827d30a25f936424210cefb2c8
  INFO [05/08/19 10:38:54:45] End: Finding merge base between 'releases/0.1.0' and 'releases/0.1.0'. (Took: 106.84ms)
  INFO [05/08/19 10:38:54:47] Git tag '0.1.0-test': 0.1.0-test with commit count source ac22ccb4dd8937a5ec46ad1504281aee490b4411 (Incremented: 0.1.0-test)
  INFO [05/08/19 10:38:54:49] Found multiple base versions which will produce the same SemVer (0.1.0), taking oldest source for commit counting (Version in branch name)
  INFO [05/08/19 10:38:54:53] Base version used: Version in branch name: 0.1.0 with commit count source ac22ccb4dd8937a5ec46ad1504281aee490b4411 (Incremented: None)
INFO [05/08/19 10:38:54:53] End: Calculating base versions (Took: 448.82ms)
INFO [05/08/19 10:38:54:58] Skipping version increment
INFO [05/08/19 10:38:54:60] 2 commits found between ac22ccb4dd8937a5ec46ad1504281aee490b4411 and 7f8ef13e5f43d3827d30a25f936424210cefb2c8
INFO [05/08/19 10:38:54:64] Begin: Getting version tags from branch 'refs/heads/releases/0.1.0'.
INFO [05/08/19 10:38:54:68] End: Getting version tags from branch 'refs/heads/releases/0.1.0'. (Took: 46.60ms)
Run Code Online (Sandbox Code Playgroud)

最后,您可以看到它正在跳过版本增量。但我不知道为什么。

KUT*_*ime 1

这可能是因为 GitVersion 任务中的错误。

我对 GitVersion 任务 v5.0.1 也有类似的错误,它是 Azure DevOps Pipeline 中的默认版本。无论我对主分支做了什么,GitVersion 每次都会给我相同的版本。我的策略是Mainline

我在这个任务设置中使用了名为 UseGitVersion 的 GitVersion版本

# Temporary fix to update GitVersionProperly
- task: UseGitVersion@5
  inputs:
    versionSpec: '0.0.0'
Run Code Online (Sandbox Code Playgroud)

此设置安装了 GitVersion 任务工具的 v5.1.2,它产生了正确的版本控制,或者至少根据我对过程的期望和理解。