0

I'm trying to set up a DevOps pipeline for a .NET Standard library project for a NuGet package. I'm using GitVersion for keeping track of semantic version for the package. I do the build with VSBuild@1 task so I just include GitVersion as GitVersion.MsBuild package.

I aim to use a simple GitHubFlow as work flow, so I configure GitVersion for mainline mode. I only use feature and hotfix branches and would like to merge all feature branches to master with a pull request only. The GitVersion configuration I use is like this:

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

All version increments are working perfectly fine, expect for the pull request completion. Pull reguest gets the same version as the feature branch, but when it gets merged to master, the master version gets incremented by the amount of commits to pull request.

An example:

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

Why does it behave this way? Is there any way to get the master to set on the same version with pull request, like 1.3.0 in the example above?

--- EDIT ---

As is the case most often - at least with me, this turned out being a user error. The GitVersion tool was working as expected.

When merging pull request to master, I used "rebase and fast-forward" merge type. This, naturally, caused the observed behaviour. The first commit in pull request content got the expected version, while all subsequent ones got incremented with default patch increments. I changed merge type to "squash merge" and voilà, master branch versioning works just like I wanted it to work.

riQQ
  • 9,878
  • 7
  • 49
  • 66
Yuhis
  • 502
  • 8
  • 16

1 Answers1

0

I see Yuhis updated the issue description, so this issue is caused by choosing improper merge strategy when merging pull request to master.

If you use "rebase and fast-forward" merge type. The first commit in pull request content got the expected version, while all subsequent ones got incremented with default patch increments.

If you change merge type to "squash merge" and then master branch versioning works as expected.

See: Complete the pull request for more details. enter image description here

Edward Han-MSFT
  • 2,879
  • 1
  • 4
  • 9
  • Hi Yuhis, If this answer works in your side, you could Accept it as an Answer, it could help other community members who get the same issues, thank you. – Edward Han-MSFT Mar 26 '21 at 07:21