[Bug] GitVersion calculates the wrong version after `main` is merged back to `develop`

[nZeus]

Describe the bug
Our config file looks like this:

branches:
  main:
    mode: ContinuousDeployment
  develop:
    mode: ContinuousDeployment
    tag: "alpha"

Imagine that we have the following tree:

When I run dotnet-gitversion | jq '.FullSemVer' on develop, I get the correct version:
2.0.0-alpha.1

But after I merge main to develop, I get the wrong version calculated:

1.1.0-alpha.3

Expected Behavior

I expect gitversion to respect commits from develop branch and calculate version 2.0.0-apha.X

Actual Behavior

Commits from develop are ignored, gitversion calculates the version from the last tag, which in this case is in the "sub-branch" of develop

Context

We have to apply an empty +semver:major commit every time main is merged back to develop.

Your Environment

• Version Used: 5.12, and 6.0.0-bet.3
• Operating System and version (Windows 10, Ubuntu 18.04): Windows and MacOS

[HHobeck]

I'm not sure if it is a bug or feature. Anyway I see your use case. When merging from master to develop why not just do a rebase?

[tomachristian]

Thank you for your reply! Interesting option with rebasing, but we would prefer not to rewrite the history of our develop branch. Is there any other option built-into GitVersion that we might be able to use?

[nZeus]

Hi @HHobeck .

Do you mean rebase of develop over master? That's not an option as there are many developers working on new features, and all of them would have to do extra steps every time develop gets new hashes.
Let's imaging we have develop branch with commits sha1, sha2.
Let's make a PR from feature_1 branch (sha3) to develop. You only see a single commit in the PR (sha3).
If you rebase develop over master, sha1 becomes sha1', sha2 -> sha2'.
Since feature_1 was not rebased over new develop, we would see sha1, sha2 and sha3 in our PR, which is wrong. So all developers would also have to rebase their PRs...

In addition to this rebasing of develop over master would be a painful process because of conflicts (that we would have to fix with the help of people that did the changes)..

---

This release strategy is a variation of GitFlow, but it's a light-weigh version of it (excl. release branches, and up-merges come from master->develop, instead of from hotfix->develop). But in comparison with GitFlow, it guarantees that every hotfix that was made to master gets to develop (while in GitFlow someone might forget to up-merge hotfix to develop)

[HHobeck]

Hi @HHobeck .

Do you mean rebase of develop over master? That's not an option as there are many developers working on new features, and all of them would have to do extra steps every time develop gets new hashes. Let's imaging we have develop branch with commits sha1, sha2. Let's make a PR from feature_1 branch (sha3) to develop. You only see a single commit in the PR (sha3). If you rebase develop over master, sha1 becomes sha1', sha2 -> sha2'. Since feature_1 was not rebased over new develop, we would see sha1, sha2 and sha3 in our PR, which is wrong. So all developers would also have to rebase their PRs...

In addition to this rebasing of develop over master would be a painful process because of conflicts (that we would have to fix with the help of people that did the changes)..

This release strategy is a variation of GitFlow, but it's a light-weigh version of it (excl. release branches, and up-merges come from master->develop, instead of from hotfix->develop). But in comparison with GitFlow, it guarantees that every hotfix that was made to master gets to develop (while in GitFlow someone might forget to up-merge hotfix to develop)

From the git flow point of view I would always recommend to make a rebase from develop to any feature branches. Merging from develop to the release branch you can run into problems as well (see the discussion #3177). The reason is to get a cleaner history and of course not run in this problems you are facing here. At the end if you as a developer are creating a new feature you always do it on a history base like e.g. develop branch. If you are done the development one this basis instantly or with merging it x times it makes no difference and also no one cares. It gives no additional information to you or other developers. At the end we talking about how difficult it is to merge changes with rebase or with normal merge strategy. And here I'm not certain if I can sign your statement that the merge conflicts are more complex to solve in case of rebasing. An alternative solution like you already pointed out would be to always merge the changes from the hotfix to develop branch sure.

[HHobeck]

Thank you for your reply! Interesting option with rebasing, but we would prefer not to rewrite the history of our develop branch. Is there any other option built-into GitVersion that we might be able to use?

I want to point out that also having direct commits on develop branch with bump messages is very unusal. Normally the motiviation using bump message is directed in the scope of the feature development (see this comment #2958 (comment)). And if you do a rebase from develop to feature branch then you are fine. That' means you can do a merge from main to develop with merge message as long you are consider this workflow.

[nZeus]

Sorry for a long delay - we've been busy with some other stuff..

From the git flow point of view I would always recommend to make a rebase from develop to any feature branches.

I'm not sure I understand you correctly. The original GitFlow is actually merge-base solution, but that's regarding the feature branches. As for develop branch - it must be protected in GitFlow (and, actually, in most/all git strategies).
We also keep develop branch protected, while feature branches can (must) be rebased over the latest develop before they are merged.

Merging from develop to the release branch you can run into problems as well (see the discussion #3177).

We don't merge develop to release branch. But we need to up-merge hot-fixes to develop. This is the scenario where we have issues now.

The reason is to get a cleaner history and of course not run in this problems you are facing here.

Oh yeah, we also like to have a cleaner history, and simple process. That's why we optimized the GitFlow strategy to our needs. But conceptually it's still very close to GitFlow.

At the end if you as a developer are creating a new feature you always do it on a history base like e.g. develop branch.

That's correct

If you are done the development one this basis instantly or with merging it x times it makes no difference and also no one cares. It gives no additional information to you or other developers.
At the end we talking about how difficult it is to merge changes with rebase or with normal merge strategy. And here I'm not certain if I can sign your statement that the merge conflicts are more complex to solve in case of rebasing.

Well, when you rebase a branch, you need to take care of each commit in that branch. And the bigger the branch is, the more difficult it may be. Especially, if something was moved/refactored back and forth.

An alternative solution like you already pointed out would be to always merge the changes from the hotfix to develop branch sure.

I want to point out that also having direct commits on develop branch with bump messages is very unusal. Normally the motiviation using bump message is directed in the scope of the feature development (see this comment #2958 (comment)). And if you do a rebase from develop to feature branch then you are fine. That' means you can do a merge from main to develop with merge message as long you are consider this workflow.

I think the issue here is that if you're merging 2 branches, and one of them has tags, while another - doesn't -> gitversion completely ignores the other branch.
Let's abstract from git strategies and branch names.
Let's just think of 2 branches: B1 and B2. Let's assume the root of both branches was v1.0.0; let's imaging there is a commit +semver:major in B1, and a tag v2.0.0 in B2. It's a weird example, I know, but it highlight the issue very well. What version should the merge commit have? I beleive it should be v3.0.0-alpha. But gitversion would calculate v2.x.x-alpha.

We tested a work-around: we decided to manually tag the branch with the +semver:major commit. This way forces gitVersion to respect both branches.

But we would love to have an option in gitVersion to somehow respect both branches during merge 🙏.

Kind regards,
Ilia

[arturcic]

@HHobeck isn't the merged PR fixing the problem?

[HHobeck]

I think we need to revert it. The fix is not right unfortunately.