Question: Merge-Commit and tags

[jonahbohlmann]

Hello,

I am new to GitVersion and have questions.

Normally we use GitFlow (and I think I have the same problem there) but for some smaller repositories like infrastructure (where some dockerfile located) we just have feature/bugfix + develop + master.
But of course: a release branch would not resolve the issue, as I can see.

We use BitBucket and Teamcity.

The plan:

• feature branch = minor +1
• hotfix and bugfix = patch +1

Flow:

• I create a feature branch: feature/my-new-feature and implement changes
• I create a PR and after approvals, I merge to develop.
  - In develop I have the commit and a Merge-Commit
• TeamCity start a build, calculate the version with GitVersion and set as build number. Also create a alpha tag. (example 1.0.0-alpha)
• Then we merge develop to master (or we create a release branch from develop and merge the release branch to master)
• In master I have at least three commits: Commit, PR1 and PR2 merge commits.
• Again, Teamcity start and calculate the version and creates a tag (1.0.0) on last commit
• If I do the same again, the develop pipeline would again build the version 1.0.0-alpha and the master pipeline would end in 1.1.0

I think the problem is because teamcity uses the latest commit for Tagging. But the Merge-Commit (where the tag was created for) is not in develop branch.

When I merge master back to develop, develop also has the commits and tag for 1.1.0, so next version in develop would be 1.2.0, then it is fine again.

This is because of merge-no-ff.

When I use merge-ff it is working because there are no merge commits. So the tags are created on commits which are also available on develop. But then I can not separate between feature and bugfix merges and I only be able to increase the minor version. patch number can only be changed with commit message. This is not good.

I plan that we have SemVer without any doing from developer side (at least in most cases).

Is my problem understandable? Any idea? What is wrong from my side?

Thank you!

Best Regards

[asbjornu]

Not using fast forward merges is the right way to go with GitVersion, as that keeps the branched commits and merge-commits intact. Can you write a RepositoryFixture test or a number of command line statements showing what is happening and what version you would expect at each step? I'm not sure I understand what your expectations are.