Commit message can bump major version twice in GitFlow #2667
Description
The problem
I dont' know if this is intended use, but commit-message incrementing doesn't seem to work with GitFlow. I want to add a commit message with semver:major at the point of the breaking change, to allow correct major version assignments for system testing between releases. The documentation around manual increments doesn't appear to give any caveats in this regard.
I've supplied a test illustrating this issue. This isn't exactly how I hit it, but is simpler and easier to understand. Instead of being based on 2.0.1, the assigned FullSemVer is 3.0.0-beta.1+6.
The immediate cause seems to be BaseVersionCalculator.FixTheBaseVersionSourceOfMergeMessageStrategyIfReleaseBranchWasMergedAndDeleted(), which takes the merge commit message from release 2 and reassigns the merge base to the original branching commit for release/1.0.0. This in turn causes the semver commit message to be counted again while incrementing from the base version. This code affects commit counting, which is fair enough, but I'm surprised it's allowed to effectively modify the major version number.
Workaround
I can avoid the problematic method by having a single release/X.Y.Z branch anywhere in the repository. However, I'm not generally a fan of relying on side-effects like this.
The double-bump effect also disappears in the release after the one with the major increment, i.e. there is no triple-bump. However, in my actual use-case (see below) I'm still stuck with an unwanted major version increment.
Test code
using var fixture = new BaseGitFlowRepositoryFixture("0.1.0");
MakeRelease(1);
fixture.Repository.MakeACommit("+semver:major");
MakeRelease(2);
fixture.Checkout(MainBranch);
fixture.BranchTo("hotfix-2.0.1", "hotfix");
fixture.MakeACommit();
fixture.AssertFullSemver("2.0.1-beta.1+1");
void MakeRelease(int majorVersion)
{
var releaseBranchName = $"release/{majorVersion}.0.0";
fixture.BranchTo(releaseBranchName);
fixture.Repository.MakeACommit();
fixture.Checkout(MainBranch);
fixture.MergeNoFF(releaseBranchName);
fixture.ApplyTag($"{majorVersion}.0.0");
fixture.Checkout("develop");
fixture.MergeNoFF(releaseBranchName);
// If I remove the next line, this test passes
fixture.Repository.Branches.Remove(releaseBranchName);
}Footnote
In our actual repo, we implement GitFlow with a merge from main back to develop at each release, which I understand is fairly common. This issue then appears on develop, meaning it is not only an issue for hotfixes. However, I think the above example is easier to explain and reason about.