Does the increment setting override Commit and Merge Descriptions?

[ArnavBhutaniLithia]

If I have a GitVersion.yml with the following contents:

mode: ContinuousDelivery
branches:
  main:
    increment: Minor
ignore:
  sha: []
merge-message-formats: {}

and I make commits such as the following:
git commit -am 'foo bar foo bar foo bar +semver:patch'

I notice that the tag increments by minor regardless of the commit message containing +semver:patch.

Which would make sense if the increment: Minor is applied to every commit regardless of the merge message.

If this is the case, is there a way to override the increment parameter in commits/merge messages? Or should I just default the PR description to contain +semver:minor via templates and set the default increment to patch?

[HHobeck]

Please see the following answer in discussion: it doesn't seem to bump the version correctly

You need to think about the use case of using the bump message feature. The motivation is more dependent on what changes your commit includes from the development perspective. When you in the role of a developer don't care about what the target branch might be and think: "Oh it's not just a minor change it’s a huge change which should yield to a major version increment because I have updated the API with a breaking change." Hope that's understandable.

[ArnavBhutaniLithia]

Thanks for the reply,

I hadn't seen that post. Thanks for pointing it out to me, that confirms some of my suspicions as to what is going on.

The workflow that I'm trying to simulate is that the default merge into our main branch is a minor increment (which is where the increment: Minor comes from). But sometimes I make a mistake and I need to fix a release (Eg. a patch release). How would I override the increment: Minor using GitVersion? Adding +semver:patch in the commit message (or PR description in Azure DevOps) doesn't override the version as you pointed out. Am I using the wrong mode? Or perhaps increment isn't the right setting for my workflow?

Thanks in advance.

[HHobeck]

In a trunkbased workflow (Mainline) you would:

• specify the main branch with increment: none
• merge a feature/just-a-feature branch in main for minor changes
• merge hotfix/just-a-hotfix branch in main for patch changes

In a non-trunkbased workflow (e.g. GitFlow) you would:

• specify the main branch with increment: patch
• specify the hotfix branch with is-release-branch true (see [Bug] VersionInBranchNameVersionStrategy only considers the release branch #2693)
• merge a release/X.X.0 in main for minor or major changes
• merge hotfix/X.X.X or hotfix/what-ever branch in main for patch changes

What I'm trying to say is that you need to follow the merging and branching strategy which is dependent of your wokflow of course. If you have a feature and think oh it's not a feature it's a bug fix why do you not follow just the rules!? Please see the following sequence diagrams: https://gitversion.net/docs/learn/branching-strategies/gitflow/examples

[ArnavBhutaniLithia]

I think my workflow most resembles the mainline flow that you described and is described here: https://gitversion.net/docs/reference/modes/mainline. We just tag the version on the branch after every merge, which seems to be fine/desired according to the documentation.

After doing some testing on my end I think mainline does do what I need it to do.

In case someone else stumbles upon this thread, using mainline mode like this:

mode: Mainline
branches:
  main:
    increment: Minor
ignore:
  sha: []
merge-message-formats: {}

Makes every merge (You don't need to specify feature/xxx) into main a minor version bump, but you can still override the version bump with merge and commit messages such as +semver:patch (so you don't need to name branches as hotfix/xxx) and +semver:major.

If you have a feature and think oh it's not a feature it's a bug fix why do you not follow just the rules

I think I got tripped up on the fact that I inherited this system and that we aren't using any naming conventions for our branches. So the examples weren't working well in my mind. In addition, from what I can tell, when gitversion was initially setup mainline mode hadn't been released yet. I've ended up with a bunch of different gitversion.yaml files scattered around in repositories and parsing them has been a bit of a nightmare. I just started with this file since it is quite simple haha. Now that I have an example to start with I can work to start standardizing our gitversion setup and reduce our gitversion files to only a couple of configurations based on workflows.

Regardless, I appreciate your help,
Arnav

[HHobeck]

I'm not understanding why you are still specifying increment: Minor on main branch. The problem remains if you ask me when you are merging to main. Thus you cannot override the behavior with +semver: patch on the merge commit message right!?

Edit: Of course at the end they are more than one solution to manipulate the next semantic version number with git-version ;)

[ArnavBhutaniLithia]

I'm not understanding why you are still specifying increment: Minor on main branch

Its just a default version bump. We assume that most changes being merged are going to be backwards compatible feature additions/removals, which should be minor bumps according to semver. That way we don't have to enforce branch prefixes or commit message formats for most merges.

The problem remains if you ask me when you are merging to main. Thus you cannot override the behavior with +semver: patch on the merge commit message right!?

Not sure if I'm following what you are saying, but do you think I will still run into issues with the merge message? From my (limited) testing I am seeing this is the behavior with the two modes:
Gitversion mode: ContinousDelivery

% gitversion
{
  "Major": 2,
  "Minor": 10,
  "Patch": 0,
  ...
}
% git commit -am 'test patch release +semver:patch'
% gitversion
{
  "Major": 2,
  "Minor": 11,
  "Patch": 0,
  ...
}
% git reset HEAD~
% git commit -am 'testing +semver:major'
% gitversion
{
  "Major": 3,
  "Minor": 0,
  "Patch": 0,
  ...
}

GitVersion mode: Mainline

% git reset HEAD~
% gitversion
{
  "Major": 2,
  "Minor": 10,
  "Patch": 0,
   ...
}
% git commit -am 'test patch release +semver:patch'
% gitversion
{
  "Major": 2,
  "Minor": 10,
  "Patch": 1,
  ...
}
% git reset HEAD~
% git commit -am 'test minor release'
% gitversion
{
  "Major": 2,
  "Minor": 11,
  "Patch": 0,
  ...
}
% git reset HEAD~
% git commit -am 'test major release +semver:major'
% gitversion
{
  "Major": 3,
  "Minor": 0,
  "Patch": 0,
  ...
}

I tried doing a sample merge locally, and it seems to be consistent with the commits that I have tested in Mainline mode.

[HHobeck]

I have checked it. Yes you are right it seems to be working in the actual version of git-version for mainline. But I'm not sure if this behavior will remain in future releases. Because it's very confusing and probably a bug. I would recommend you to specify the main branch with increment none or minor patch and let git-version automatically extract the information from the merge commit message.