Support multiple concurrent release/hotfix branches

[nvie]

Take care of the situation where two release branches live next to each other. In that situation, a "finish release" action should merge back changes into the other release, not into 'develop'. Or at least warn about it. Or not support creating a new release branch if the other isn't finished yet.

[chrishas35]

If I'm reading this right, this is to cover situations where I have tagged and released 1.0, and am actively working on 1.1, but might need to apply some fixes for a 1.0.1 release that are also included in 1.1. Is that correct? If so, I'm interested in seeing this functionality too. Do you have an idea as to how you might like to see this implemented so others might contribute?

[nvie]

This wouldn't be the case if you have already "released" 1.0. Because a release would mean you have finished the release branch and tagged the commit on master. So effectively, after releasing, your release branch is gone.

However, problems arise when you start a release branch, and while applying the latest bugfixes on that release branch, some hotfix needs to be created. Since the hotfix is branched-off from master and merged back into master+develop, this would bypass the currently active release branch.

In effect, you would:

1. Introduce the bug again in the next release; or
2. Risk changing behaviour (untested) when merging the release branch back into master. Note that the last commit on the release branch and the merge commit on the master branch should ideally have no code changes (i.e. should ideally be no "real" merge). This changes that situation. You're going to tag something that hasn't been tested.

For implementors/contributors: A way to deal with this problem would intuitively be the following. (Note that I haven't thought this through yet in great detail.):

When finishing a release/hotfix branch, we should merge changes into master and develop (like regular), but additionally merge that release/hotfix branch into every other existing release/hotfix branch too.

Note that this may well become unwieldy quickly if there are lots of concurrent release/hotfix branches. If there exist n release and m hotfix branches, this implies 2 + n + m - 1 merges.

[idar]

I see the problem, though as a team, we often have multiple hotfix branches. I would like to have support for multiple hotfix branches. Maby add code so when they are finishes its merged into all release branches also.

[baby-gnu]

Hello,

+1 to multiple hotfix branches

Sometime, it take long time for a bug to get solved, and if an easier one is opened, I prefer to close it as soon as possible.

Other time, hotfixes are imbricated:

• new bug number 13 => new hotfix branch hotfix/13
  hmm, this result in a bad interaction due to another bug
• new bug number 23 (arf, too much bug in so little time... ) => new hotfix branch hotfix/23
• solve and finish hotfix/23 => new release 1.0.1
• rebase hotfix/13 on hotfix/23
• solve and finish hotfix/13 => new release 1.0.2

Regards.

[baby-gnu]

The require_no_existing_hotfix_branches() function can be removed with my pull request to Peter van der Does

When finishing a hotfix, must be ahead of the production release branch, this require the branch to be rebased/renamed.

We could decouple the hotfix branch name and the version number.
And then change the cmd_start() and cmd_finish() prototypes to:

git flow hotfix start <name> [<base>]
git flow hotfix finish [-n <name>] <version>

The name would be calculated from <version> except if option -n <name> is passed

The same logic can be applied to release branches.

[baby-gnu]

After some tests an thoughts I got the following interface:

usage: git flow hotfix [list] [-v]
       git flow hotfix start [-F] <name> [<base>]
       git flow hotfix finish [-Fsumpknb] <version> [<name>]
       git flow hotfix publish <name>
       git flow hotfix delete [-fr] <name>

This imply changes only to version filter (#186), the version is only required when finishing a hotfix (the same applies to release)

Except the semantic, lhe real new thing is the optional <name> parameter:

• If omitted, use hotfix/<version> as branch to merge

• if provided use it as branch to merge:

  git flow hotfix finish 1.1 42 -> merge branch hotfix/42 to production release branch

Done in baby-gnu/gitflow@0abbb45

[baby-gnu]

Looking at Peter van der Does code there is a possible issue with tags:

• hotfix branch is merge into production release branch
• if user want tag and the tag does not exists, tag the current HEAD

I think we could make a better sanity check on the tag, before merging to the production branch:

• if user want tag and the tag exists, it must point to a merge commit with the hotfix branch as parent.

Done in my permit multiple hotfix branch (baby-gnu/gitflow@54cc9cb)
Done for release in my develop branch (baby-gnu/gitflow@961ebcd)

[spiffytech]

I am unclear on the status of this issue. Why has @baby-gnu's commit not been merged in? Does it fail to resolve all issues? I would really like to be able to start and finish multiple hotfix branches concurrently, and independent of each other.

[Elijen]

@spiffytech +1

[lpanebr]

+1 for multiple hotfix branches concurrently.

+1 is important feature!