How to use GitVersion to get sensible versioning

The challenges of versioning

It’s surprising to see that some teams are still struggling with the numbering of their DLLs, NuGet or NPM packages. Some rely on build numbers, some number them by hand by committing a version to source control, and some don’t even care about all of this.

Numbering your artifacts in such a way that they convey a certain level of stability is a matter of maturity that all teams should be adopting. And this goes hand-in-hand with a well-defined branching and merging strategy. In fact, combining the clarity of Semantic Versioning, a release strategy like GitFlow or GithubFlow and GitVersion gives you all of this practically for free.

To demonstrate this, let me show you a typical development workflow. So let’s assume you have been developing your newest marvel of a software package on a main or master branch and you’ve are tagging the first official release as 1.0.0.

> Git checkout main
> Git tag 1.0.0

Let’s start by installing GitVersion. If you’re on Windows and you use Chocolatey, this is what brings magic to your machine:

> choco install gitversion.portable --yes

Now run gitversion from your console or bash. It’ll give you the following output:

> gitversion
{
"Major": 1,
"Minor": 0,
"Patch": 0,
"PreReleaseTag": "",
"PreReleaseTagWithDash": "",
"PreReleaseLabel": ""…