Asbjørn Ulsberg

`feature` branches are not supposed to be branched off of `release` branches. What happens if your feature branches are branches off of `develop` instead?

> Thus all commits in the release branch should be reviewed and ensured via a gate (Pull Request and/or CI-Pipeline) as well right!? How would you do this? You create...

Yes. The source branches of `feature` [is documented](https://gitversion.net/docs/reference/configuration) as well: ```yaml source-branches: [ 'develop', 'main', 'release', 'feature', 'support', 'hotfix' ] ``` But as you can see, `tracks-release-branches` is also set...

Why would you set `tracks-release-branches` to `true` for `release` branches? Shouldn't the configuration rather be something like this? ```cs var configuration = new Config { Branches = new Dictionary() {...

I haven't investigated why, but I managed to get something close to what you're expecting with the following configuration: ```cs var configuration = new Config { Branches = new Dictionary...

#3151 seems to be a duplicate of this, or at least very relevant. So I think there is enough interest to fix this somehow. Changing the behavior of `increment: Inherit`...

I like your observations and suggestions, @HHobeck. That part of the code is indeed in need of some serious love and refactoring. The only big question is how many existing...

You have to fork the repository and push to a branch in your fork. [You then create a pull request from your fork](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request-from-a-fork).

The workflow you are describing is not supported by GitVersion. The closest match you have may be Mainline mode, but tags are going to have the highest weight when figuring...

Perhaps I'm not properly understanding your use-case. Please submit a PR with a `RepositoryFixture` that implements the behaviour you'd like to see.