Need help understanding branching, merging and config

[roddharris]

I'm new to GitVersion and still trying to understand how to properly configure it for my scenario.

We basically have a master branch that serves as our current release branch. For any changes, we create a new branch from master, make changes and commit. Finally, we merge that branch back into master.

I haven't been able to get things to successfully work as I expect. I'm convinced its because I lack understanding of how to properly configure GitVersion for what I'm trying to accomplish.

From everything I've read, there seems to be a few different ways to affect the SemVer that gets generated during a build.

1. Prefix the branch name with feature- or major-, etc.
2. Prefix a commit comment with +semver:minor, etc.
3. Add a tag like v1.0.1 to a commit.

Where I get a little confused is how things are handled when merging a branch back into master.

1. Do I have to explicitly add specific content to merge messages to indicate my expectation?
2. Will GitVer recognize the branch name prefix or commit prefixes of the branch being merged and generate the appropriate SemVer? (I guess this was my expectation).

Here is an example of what I'm expecting to happen:

1. Given master branch with most recent commit tagged with v1.0.0
2. Branch from master locally: feature-Feature1.
3. Push commits to local feature-Feature1 branch.
4. Push feature-Feature1 branch to remote (Azure Devops).
5. Pipeline kicks off build and GitVer generates SemVer of : 1.1.0-Feature1.1 (expected based on my understanding)
6. Merge feature-Feature1 branch into master on remote (Azure Devops) (with Azure's default merge message)
7. Pipeline kicks off build and GitVer generates SemVer of 1.0.1 (not expected, was expecting 1.1.0)

As you can see, I expected a different result in step 7 given that the branch I merged into master was a feature branch.

Questions

1. Given my branching/merging strategy above, should I be using GitHubFlow/v1 workflow or TrunkBased/preview1? (I've tried both and I haven't seen any difference).
2. When I merge a feature branch into master, should I be doing a Squash Merge or a Merge (no fast forward)?
3. I think my expectation was that because the branch was defined as a feature branch, when merging, GitVersion would automatically pick up on that and increment the minor version of the master branch. Is my expectation wrong?
4. In playing around, I noticed that if I override my merge message and start it with +semver:minor, this does seem to increment the minor version number during the build of master. Is this required or are there other ways to affect this?

[HHobeck]

I think this answers your question:

• Does GitVersion 6 still support the logic to step minor on feature/XX and path on bugfix/xx branches? #4217
• Mainline not behaving as expected. PR and merge to main are not incremeted as expected #4024
• Mainline Not Incrementing SemVer when merging to main with AzureDevops #3800