GitVersion Mainline - Version increment on every push

2.1k Views Asked by At

I am using GitVersion with Mainline mode. With default settings, it increases patch number with every commit in master. Is there a way to increase patch number on every push rather than on every commit?

If I push 3 commits together, patch gets increased by 3. In this case I would get version jump from 2.0.4 to 2.0.7 on VSTS build.

GitVersion.yml

mode: Mainline

Note: I have got only one branch, which is 'master' and I will be keep pushing my changes to master directly. I am not looking to use any branching strategy yet.

2

There are 2 best solutions below

0
On

The short answer is no - sorry :(

However, if you did decide to simply use two branches, you could simulate this by using Git's "Squash and Merge" strategy to achieve it. Basically, all of your commits would become a single commit on the main branch (master) after merging.

Feels simple enough to warrant it as a suggestion :)

0
On

As I see it, you have two options avaliable to you.

You could override increment: None for your master branch configuration:

branches:
  master:
    increment: None

But then, I think you would always need to "manually" bump the version of your code through git commits, such as including in your commit message: +semver: (major|minor|patch), or updating your GitVersion.yml file to set the next-version configuration. This, I think, defeats many of the benefits of using GitVersion at all. But, this is still better than not versioning at all!

However, saying that you're doing "mainline" development, does not necessarily mean that you only develop in the master branch. I believe that mainline development mainly implies that you release off of the master branch (i.e. you're not using GitFlow with two long-lived branches, master and develop) and that the state of master at any point in time is deployable to production.

So you could achieve what you're looking for using two different branches as @prestonsmith already said in his answer. You and your team could work in short-lived topic branches off of master, and eventually merge (either normal merge-commit to preserve history, or squash merge (loses branch history and just introduces a single commit into master with all the changes created on the topic branch). This would result in the default behavior of a single patch version increment, which could later be changed to a minor or major increment via the use of git tags or, in your merge commit message, adding something like +semver: (major|minor) to instead increment the major or minor version number.