Use increment from merged branch in mainline mode

[mchippingtonderrick-afl]

Creating a new issue as my original issue received no attention, and what I am asking has changed somewhat.

I am using an extremely simple mainline branching strategy, with a single master branch, and major, minor, and patch branches, with matching version increments.

I want any merge into the master branch to use the version number / version increment from the merged branch. However, when I merge with my current configuration, it uses the increment for the master branch.

Example trimmed history:

*   88b69a1  (master)  <- Want to calculate as 1.7.0
|\
| * b906ad1  (minor/example-2) <- Correctly calculates as 1.7.0
| * aaa9925
| * e0efa7d
|/
*   0ad16d9 <- Want to calculate as 1.6.2
|\
| * e9124c8  (patch/example-1) <- Correctly calculates as 1.6.2
|/
*   5a3e359 (tag: 1.6.1)

What do I need to do to achieve this behaviour?

[asbjornu]

This behaviour isn't supported out of the box by GitVersion. As a matter of fact, #1541 might even have made your use-case work less. You might be able to mimic it with the merge-message-formats configuration introduced in #1488 or by configuring your patch/*, minor/* and major/* branches as release branches with something similar to:

release:
    regex: (major?[/-])|(minor?[/-])(patch?[/-])

[mchippingtonderrick-afl]

I'm quite surprised that this isn't something that GitVersion can do honestly; and it leaves me unsure of how branch specific increments are supposed to be used then.

Also, I really don't see how setting up the different work branches with a single release branch configuration could help here, as I wouldn't be able to set the increment differently for each of them.

[asbjornu]

Your Git flow is unique. I've never seen anyone do anything like you do in my 10 years of working with Git and 5 years of working with GitVersion. Being surprised GitVersion doesn't support your flow is therefore … surprising to me. 😄

Branch-specific increments is based on pre-existing knowledge about what each branch is used for. Perhaps you could set it up so your patch branch is treated as develop, your minor branch as feature and your major as release? It might be worth a shot.

[mchippingtonderrick-afl]

I'll admit, I'd been put in the situation of needing to sort out doing this from having never really had any real instruction on what standard git branching strategies there are, and how to use them; so I more or less ended up putting together the simplest method I could think of.

I guess I'm also just a bit surprised that it's not something that's been done before, since it's almost exactly what's depicted in the diagram for mainline development in the documentation; except determining the increment from the branch name, rather than marking the increments manually.

I'll also try switching the branch configurations onto those as you said, and see how I get on.

[asbjornu]

If you used develop, feature and release branches as specified in Gitflow, you'd have a flow that GitVersion understood and supports. Creating your own flow with your own custom-named branches makes this a less "out of the box" experience. Please try the suggested config and let me know how it works out for you.

[ActSabke]

I do not think that this request is strange. We would like to do the same thing.
When a developer creates a branch he already knows if it is a feature or a bugfix. Feature branches have a minor increase and hotfix branches a patch increase. When he merges his branch (through a pull request) into master we would like to increase the master version accordingly the source branch.
I've found an old post with the exact same question (crf #1221). This issues states that it would be available in V4.

[asbjornu]

@ActSabke, what's being discussed in #1221 only applies if the source branches are actually identified as feature branches. GitVersion can't read the mind of developers, so whether they know a branch is a feature branch or a bugfix doesn't help GitVersion one tiny bit.

The only way GitVersion can know whether a branch is X or Y is by convention or configuration. If you deviate from the convention, you need to apply appropriate configuration. If you deviate enough, even configuration won't help you. Sorry, but GitVersion is not made to support every thinkable, home-grown, self-invented branching strategy.

GitVersion supports less than a handful well-documented, best-practice branching strategies and if they don't suit your needs and you're having a hard time getting GitVersion to work for you, I'm sorry to say GitVersion might not be the right tool for you.

[mchippingtonderrick-afl]

@ActSabke I think I've got my configuration for this working now, but had not yet updated this issue as I've not been able to test it thoroughly on our remote system.

I believe that the issue that I'd been encountering before was that GitVersion was parsing the remote name as part of the branch from GitHub's merge commit messages, and was not matching the associated branch configurations as a result.

I'll also explicitly warn not to edit the merge commit message, as that has tripped me up a couple of times before I'd realised that GitVersion was using it to identify the names of the merged branches.

Here is the configuration I am currently using:

mode: Mainline

branches:
  # Using custom branch configurations to ensure that no default configuation muddles things.
  # "remote" here should be replaced by the name of the git-hub organisation to be able to
  # match branch names in github pull request merges correctly.
  master:
    regex: '(remote/)?master'
    tag: ''
    increment: None
  clean:
    regex: '(remote/)?(clean|none)[/-]'
    tag: useBranchName
    increment: None
    source-branches: ['master']
    mode: ContinuousDelivery
  patch:
    regex: '(remote/)?(patch|((bug-?)?fix))[/-]'
    tag: useBranchName
    increment: Patch
    source-branches: ['master']
    mode: ContinuousDelivery
  minor:
    regex: '(remote/)?(minor|feature)[/-]'
    tag: useBranchName
    increment: Minor
    source-branches: ['master']
    mode: ContinuousDelivery
  major:
    regex: '(remote/)?(major|breaking)[/-]'
    tag: useBranchName
    increment: Major
    source-branches: ['master']
    mode: ContinuousDelivery
    
  # Disable default branch configs with super specific branch regex.
  feature:
    regex: '^f$'
  release:
    regex: '^r$'
  support:
    regex: '^s$'
  develop:
    regex: '^d$'
  pull-request:
    regex: '^p$'
  hotfix:
    regex: '^h$'

[ActSabke]

@mchippingtonderrick-afl, thank you for your answer.
Your clue about the merge commit message is actually the answer. We are using the gitversion tfs task. When creating a PR on tfs, the source branch name is not included into the merge commit message. That way gitversion cannot deterimine the merged branch and falls back on the target branch increment.
@asbjornu, is it possible to get the increment from the source branch if the merge commit message did not have a source branch included?

[asbjornu]

@ActSabke, sorry, but I'm unable to answer that. The only answer I can provide is that if you get GitVersion to work this way, then; yes. Otherwise; no. I have not tried myself and I don't think there's any regression tests for this scenario, so I can't guarantee that if this works now it's also going to work in the future. If you get this to work, you're more than welcome to send us a pull request that adds such a test for future-proofing your use-case, though.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. After 30 days from now, it will be closed if no further activity occurs. Thank you for your contributions.