Version Not Maintained After Merging PR

[Fenikkusu]

I'm trying to understand why project versioning is not working correctly. My project's current tag is 0.9.0. When I make a change, I push to a branch unstable/something. The version is correctly identified as 1.0.0, as I'd expect. After I merge the PR, it detects the version as 0.10.0 instead of 1.0.0.

Before Merge:

Set Output Variables for 'GitLabCi'.
GitVersion_Major=1
GitVersion_Minor=0
GitVersion_Patch=0
GitVersion_BuildMetaData=
GitVersion_FullBuildMetaData=Branch.unstable-force-version-tweaks.Sha.979be2969bae3053e9d25e85f7dce1c91658d774
GitVersion_BranchName=unstable/force-version-tweaks
GitVersion_EscapedBranchName=unstable-force-version-tweaks
GitVersion_Sha=979be2969bae3053e9d25e85f7dce1c91658d774
GitVersion_ShortSha=979be29
GitVersion_MajorMinorPatch=1.0.0
GitVersion_SemVer=1.0.0
GitVersion_FullSemVer=1.0.0
GitVersion_AssemblySemVer=1.0.0.0
GitVersion_AssemblySemFileVer=1.0.0.0
GitVersion_PreReleaseTag=
GitVersion_PreReleaseTagWithDash=
GitVersion_PreReleaseLabel=
GitVersion_PreReleaseLabelWithDash=
GitVersion_PreReleaseNumber=
GitVersion_WeightedPreReleaseNumber=60000
GitVersion_InformationalVersion=1.0.0-unstable-force-version-tweaks-
GitVersion_CommitDate=2025-07-16
GitVersion_VersionSourceSha=a40daab1ac2d4d9fd71d987f2266b6ee6ec42ae8
GitVersion_CommitsSinceVersionSource=1
GitVersion_UncommittedChanges=1

After Merge:

Set Output Variables for 'GitLabCi'.
GitVersion_Major=0
GitVersion_Minor=10
GitVersion_Patch=0
GitVersion_BuildMetaData=
GitVersion_FullBuildMetaData=Branch.development.Sha.d51cfa8249b3157ff4c857f219aff11110180553
GitVersion_BranchName=development
GitVersion_EscapedBranchName=development
GitVersion_Sha=d51cfa8249b3157ff4c857f219aff11110180553
GitVersion_ShortSha=d51cfa8
GitVersion_MajorMinorPatch=0.10.0
GitVersion_SemVer=0.10.0-alpha.4
GitVersion_FullSemVer=0.10.0-alpha.4
GitVersion_AssemblySemVer=0.10.0.0
GitVersion_AssemblySemFileVer=0.10.0.0
GitVersion_PreReleaseTag=alpha.4
GitVersion_PreReleaseTagWithDash=-alpha.4
GitVersion_PreReleaseLabel=alpha
GitVersion_PreReleaseLabelWithDash=-alpha
GitVersion_PreReleaseNumber=4
GitVersion_WeightedPreReleaseNumber=4
GitVersion_InformationalVersion=0.10.0-development-alpha.4
GitVersion_CommitDate=2025-07-16
GitVersion_VersionSourceSha=a40daab1ac2d4d9fd71d987f2266b6ee6ec42ae8
GitVersion_CommitsSinceVersionSource=4
GitVersion_UncommittedChanges=1

GitVersion.yml

mode: ContinuousDeployment
assembly-informational-format: '{Major}.{Minor}.{Patch}-{BranchName}-{PreReleaseTag}'
branches:
  development:
    regex: ^development$  # Matches only the "development" branch
    label: ""  # No pre-release label for final versions
    increment: Patch  # Default increment
    is-main-branch: true
  feature:
    regex: ^features?[/-](?<BranchName>.+) # Matches "feature/" or "features/"
    label: feature-{BranchName}  # Feature branch-specific versions
    increment: Inherit
  release:
    regex: ^releases?[/-]  # Matches "release/" or "releases/"
    label: rc  # Release candidates
    increment: Patch
  hotfix:
    regex: ^hotfix(es)?[/-]  # Matches "hotfix/" or "hotfixes/"
    label: hotfix  # Hotfix versions
    increment: Patch
  unstable:
    regex: ^unstable[/-](?<BranchName>.+) # Matches "unstable/"
    label: unstable
    increment: Major
  main:
    regex: ^main$  # Matches only the "main" branch (if present)
    label: beta  # If 'main' exists, it acts as a beta branch
    increment: Minor
ignore:
  sha: []  # List of commits to ignore if necessary

Note: I have the CI/CD configured such that running in a Pull Request will use the presumed version as an alpha version for all steps in the pipeline. After the pull request is merged, it runs the pipeline again in this same manner, with an added step to create a release (Which creates a tag). Once the tag is created, the CI/CD runs again with the tag specifically. The overall process looks as Pre-Release -> Merge -> Release Candidate -> Tag -> Release, for lack of a more specific process flow.

Given this flow, I would expect to see something like 1.0.0-unstable-new-stuff.1+2 -> Merge -> 1.0.0-development -> Tag -> 1.0.0. Instead, I'm getting 1.0.0-unstable-new-stuff.1+2 -> Merge -> 0.10.0-development.

[asbjornu]

The reason you see 1.0.0 before the merge is because unstable has configured increment: Major. This increment does not follow from the source branch into the target branch. Since branches are ephemeral, GitVersion can't base its calculation on them, their name or their configuration; it needs the required information codified and persisted in the repository. You therefore have to perform a git tag 1.0.0 on the merge commit in order to provide GitVersion with that information.

[Fenikkusu]

@HHobeck , is there a specific format that the merge message needs to be for track-merge-message to work correctly? Is that format configurable?

[HHobeck]

@HHobeck , is there a specific format that the merge message needs to be for track-merge-message to work correctly? Is that format configurable?

If you are reading the doucmentation then you will find a property with name merge-message-formats. Merge messages are detected per default as following:

GitVersion/src/GitVersion.Core/Core/RegexPatterns.cs

Lines 168 to 192 in ee7ee1c

	internal static partial class MergeMessage
	{
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string DefaultMergeMessageRegexPattern = @"^Merge (branch|tag) '(?<SourceBranch>[^']*)'(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string SmartGitMergeMessageRegexPattern = @"^Finish (?<SourceBranch>[^\s]*)(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string BitBucketPullMergeMessageRegexPattern = @"^Merge pull request #(?<PullRequestNumber>\d+) (from|in) (?<Source>.*) from (?<SourceBranch>[^\s]*) to (?<TargetBranch>[^\s]*)";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string BitBucketPullv7MergeMessageRegexPattern = @"^Pull request #(?<PullRequestNumber>\d+).*\r?\n\r?\nMerge in (?<Source>.*) from (?<SourceBranch>[^\s]*) to (?<TargetBranch>[^\s]*)";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string BitBucketCloudPullMergeMessageRegexPattern = @"^Merged in (?<SourceBranch>[^\s]*) \(pull request #(?<PullRequestNumber>\d+)\)";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string GitHubPullMergeMessageRegexPattern = @"^Merge pull request #(?<PullRequestNumber>\d+) (from|in) (?:[^\s\/]+\/)?(?<SourceBranch>[^\s]*)(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string RemoteTrackingMergeMessageRegexPattern = @"^Merge remote-tracking branch '(?<SourceBranch>[^\s]*)'(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string AzureDevOpsPullMergeMessageRegexPattern = @"^Merge pull request (?<PullRequestNumber>\d+) from (?<SourceBranch>[^\s]*) into (?<TargetBranch>[^\s]*)";

[Fenikkusu]

@HHobeck , is there a specific format that the merge message needs to be for track-merge-message to work correctly? Is that format configurable?

If you are reading the doucmentation then you will find a property with name merge-message-formats. Merge messages ared detected per default as following:

GitVersion/src/GitVersion.Core/Core/RegexPatterns.cs

Lines 168 to 192 in ee7ee1c

	internal static partial class MergeMessage
	{
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string DefaultMergeMessageRegexPattern = @"^Merge (branch|tag) '(?<SourceBranch>[^']*)'(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string SmartGitMergeMessageRegexPattern = @"^Finish (?<SourceBranch>[^\s]*)(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string BitBucketPullMergeMessageRegexPattern = @"^Merge pull request #(?<PullRequestNumber>\d+) (from|in) (?<Source>.*) from (?<SourceBranch>[^\s]*) to (?<TargetBranch>[^\s]*)";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string BitBucketPullv7MergeMessageRegexPattern = @"^Pull request #(?<PullRequestNumber>\d+).*\r?\n\r?\nMerge in (?<Source>.*) from (?<SourceBranch>[^\s]*) to (?<TargetBranch>[^\s]*)";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string BitBucketCloudPullMergeMessageRegexPattern = @"^Merged in (?<SourceBranch>[^\s]*) \(pull request #(?<PullRequestNumber>\d+)\)";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string GitHubPullMergeMessageRegexPattern = @"^Merge pull request #(?<PullRequestNumber>\d+) (from|in) (?:[^\s\/]+\/)?(?<SourceBranch>[^\s]*)(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string RemoteTrackingMergeMessageRegexPattern = @"^Merge remote-tracking branch '(?<SourceBranch>[^\s]*)'(?: into (?<TargetBranch>[^\s]*))*";
	[StringSyntax(StringSyntaxAttribute.Regex)]
	internal const string AzureDevOpsPullMergeMessageRegexPattern = @"^Merge pull request (?<PullRequestNumber>\d+) from (?<SourceBranch>[^\s]*) into (?<TargetBranch>[^\s]*)";

I spent some time cross-referencing the configuration and the code. Eventually, I downloaded the code base to step the code through Rider so I could understand what was happening better. I was able to configure the merge-message-formats correctly, but it still wasn't working. As I stepped the code, I realized the issue is that MergeMessage and subsequently ReferenceNameExtension are finding the branch name in the commit message, but then trying to parse a literal version out of the target branch. The whole release/1.0.0 style format, which is not really what I'm going for.

As I want the version number to be 100% derived from the git source without having to even manually tag the code, manually putting the version in the code will not work for my use case. (While I'm currently doing this just for my own repo, my day-job has a similar situation where we have well over 20 developers working on the code at any given time, so I want to eliminate the 'human' factor of determining which version to use.)

At this point is that I know that VersionInBranchNameVersionStrategy works. It correctly determines the version based on the branch name. This is seen in my original post. I now know that MergeMessageVersionStrategy also works in the sense that is is able to find the correct branch name in the commit message. My question now is what would it take to make a derivative of the two that uses MergeMessageVersionStrategy to scan the commits, then passes the found branch name to VersionInBranchNameVersionStrategy to parse the version. I tinkered with this a little last night, but didn't get far. At this point, I think it would be a relatively simple adjustment. I presume this would need to be a new VersionStrategy class, so as to not be too intrusive into the existing system. Beyond that, I've not thought about it any deeper at this time.

[HHobeck]

Yes, now you are saying this it comes to my mind. Therefor I have created a ticket some time ago:

• [FEATURE]: Support of prevent increment of merged branch in GitHub workflow #4433

[Fenikkusu]

Yes, now you are saying this it comes to my mind. Therefor I have created a ticket some time ago:

• [FEATURE]: Support of prevent increment of merged branch in GitHub workflow #4433

Oh, awesome. That's useful. I'll see about implementing those tests in PR #4630 ...once I get the tests working locally.

[HHobeck]

mode: ContinuousDeployment
assembly-informational-format: '{Major}.{Minor}.{Patch}-{BranchName}-{PreReleaseTag}'
branches:
  development:
    regex: ^development$  # Matches only the "development" branch
    label: ""  # No pre-release label for final versions
    increment: Patch  # Default increment
    is-main-branch: true
  feature:
    regex: ^features?[/-](?<BranchName>.+) # Matches "feature/" or "features/"
    label: feature-{BranchName}  # Feature branch-specific versions
    increment: Inherit
  release:
    regex: ^releases?[/-]  # Matches "release/" or "releases/"
    label: rc  # Release candidates
    increment: Patch
  hotfix:
    regex: ^hotfix(es)?[/-]  # Matches "hotfix/" or "hotfixes/"
    label: hotfix  # Hotfix versions
    increment: Patch
  unstable:
    regex: ^unstable[/-](?<BranchName>.+) # Matches "unstable/"
    label: unstable
    increment: Major
  main:
    regex: ^main$  # Matches only the "main" branch (if present)
    label: beta  # If 'main' exists, it acts as a beta branch
    increment: Minor
ignore:
  sha: []  # List of commits to ignore if necessary

Please specify always the workflow property. To be backwards compatible the value workflow: GitFlow/v1 will be used if not set. In the next major release we are going to change it and set the property as mandatory. In advance you are introducing a new branch configuration with name development which has the same regular expression like develop. It's not certain which configuration will be effectively used:

https://gitversion.net/docs/reference/configuration