FAQ

Why is my version not incrementing?

GitVersion calculates the semantic version, this will only change once per release. Read more about version increments.

I'm using Octopus deploy

Because Octopus deploy cannot have the same version of a package to a NuGet feed. There is no magic solution to this, but you can read more about your options at octopus deploy.

How can GitVersion run for a shallow clone or checkout on server working directories

GitVersion needs a proper git repository to run, some build servers do not do a proper clone which can cause issues. GitVersion has a feature called dynamic repositories which solves this by cloning the repository and working against that clone instead of the working directory.

I don't understand what SemVer is all about

Not a problem, we have a quick introduction to SemVer which can be a good primer to read before reading SemVer.org.

I can't use the build number for NuGet

If you have used NuGet you would notice the versions above are not compatible with NuGet. GitVersion solves this by providing variables.

What you have seen above is the SemVer variable. You can use the NuGetVersion variable to have the version formatted in a NuGet compatible way.

So 1.0.1-rc.1+5 would become 1.0.1-rc0001, this takes into account characters which are not allowed and NuGets crap sorting.

Note

The NuGetVersion variable is floating, so when NuGet 3.0 comes out with proper SemVer support GitVersion will switch this variable to a proper SemVer.

If you want to fix the version, use NuGetVersionV2 which will stay the same after NuGet 3.0 comes out

How do I choose my branching strategy (GitFlow vs GitHubFlow)

If you run gitversion init then choose Getting started wizard then choose Unsure, tell me more, GitVersion will run through a series of questions which will try and help point you towards a branching strategy and why you would use it.

Merged branch names as version source

When GitVersion considers previous commits to calculate a version number, it's important that the metadata to be considered is stable. Since branches are usually deleted after they are merged, the name of a branch can't be considered as a stable version source. Branch names are not stable, they are ephemeral.

The only place a branch name can be considered for version calculation is for the branch itself. This is typically used for release/* branches, which usually have a version number in their name. For the release branch release/1.2.3, the verison number 1.2.3 will be used to calculate the final version number for the release branch.

However, when the release/1.2.3 branch is merged into main, the fact that the merged commits came from a branch named release/1.2.3 vanishes with the branch which will be deleted. The name of the merged release branch can therefore not be considered for version calculation in the target branch of the merge.

GitHub