0

I am using jgitflow Maven plugin to make releases according to GitFlow. This works fine. Problems appear when my release is delayed, so I have to make 2 releases simultaneously.

Lets consider an example.

According to GitFlow I have to commit my production state to master branch. Thus I merge 1.0, 1.1, 1.2 releases to master. Someday 2.0 release is started. I need to make 2.0 release committed to master. But what if 1.xx is still not finished?

Committing 1.xx after 2.0 looks like a bad practise and probably will result in merge conflicts.

So my idea is to

  1. create fake dev branch for 1.xx branched from last 1.xx release. Lets call it 1.11dev

  2. run 1.xx jgitflow releases from that branch and merge them no longer to master, but to fake master branch created from last 1.xx release again, lets call it 1.11master

  3. run 2.xx releases from master branch and merge them normally to master.

This means my master branch will contain only part of 1.xx releases. Which is not good. Also this means I have to merge fixes from 1.xxdev to 'true' dev separately.

Is my understanding correct? Is there a better way?

MiamiBeach
  • 3,261
  • 6
  • 28
  • 54

1 Answers1

0

What you are touching on here is the concept of a support branch. This is where, once you have started work on 2.x, but needed to continue development on an earlier release, you would create a support branch for 1.x development.

We have covered this in the GitVersion tool, and there is some supporting documentation here:

http://gitversion.readthedocs.io/en/latest/git-branching-strategies/gitflow-examples/#support-branches

Bottom line is, once you get to this point, you essentially are running two instances of gitflow. One for the active develop branch, and another for the support branch.

Gary Ewan Park
  • 17,610
  • 5
  • 42
  • 60