gitflow Support multiple concurrent release/hotfix branches

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.

Jan 26 '10 21:01 nvie

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?

Mar 26 '10 00:03 chrishas35

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:

Introduce the bug again in the next release; or
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.

Mar 26 '10 11:03 nvie

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.

Feb 16 '11 12:02 idar

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.

Jul 06 '12 09:07 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.

Jul 08 '12 00:07 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

Jul 08 '12 11:07 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)

Jul 08 '12 12:07 baby-gnu

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.

Mar 20 '13 18:03 spiffytech

@spiffytech +1

Apr 19 '13 09:04 Elijen

+1 for multiple hotfix branches concurrently.

Aug 08 '13 17:08 lpanebr

+1 is important feature!

Aug 08 '13 17:08 ghost

Just submitted another pull for this. I'm thinking this should be a flag you can set in your gitconfig, ie:

[gitflow] hotHot = true

Sep 13 '13 21:09 stinoga

Would also love to have the option for multiple hotfix branches.

Feb 06 '14 20:02 lmartins

+1 for multiple hotfix branches

Feb 17 '14 20:02 phlawski

So it looks like this just won't ever get fixed? This issue was raised over 4 years ago. Is there not a solution? Is gitflow not being maintained anymore? If not, guess I'll just fork it and fix issues myself. However it looks like others have fixed it already, it would be nice if the fix could be accepted one way or another.

Edit: It looks like gitflow is kind of dead. No one has commited in over 2 years. If author isn't interested in maintaining anymore, perhaps others could take it over? This is a very very nice thing you guys have created (I'm very appreciative), but it's a shame so many people have to keep forking to fix issues all over the place.

Jul 02 '14 18:07 bitslasher

@bitslasher We've been using https://github.com/petervanderdoes/gitflow and have been happy with it. Still no multi-hotfix support, but it is being actively maintained.

Jul 31 '14 15:07 elistevens

work around for multiple hotfix branches is to complete work locally on one hotfix and push to remote then delete locally and create a new hotfix branch. this will let you have multiple hotfixes remotely. Not ideal, but its what i've resorted to doing in the meantime.

Sep 30 '14 15:09 travisdmathis

:+1:

Oct 05 '15 09:10 velikanov

Another not ideal way is to simply rename the hotfix branch

git branch -m hotfix/ticket-102 hotfix-pending/ticket-102

Dec 17 '15 17:12 lpanebr

@travisdmathis : it's a workaround, yes, but not always possible. Sometimes you just started a hotfix for a certain issue, and it takes a couple of days to pinpoint/fix/test before you can release. In the meantime an urgent production issue crops up that needs to be dealt with now. You have a half-finished hotfix in progress that won't be released for another couple of days, and no way to start a new hotfix until the first one is released or abandoned/deleted.

Sure, you could manually

create a regularbranch off of the first hotfix branch (git co -b)
cease work on the original hotfix branch
remove it
start the new, urgent hotfix branch from master
finish that
then create a new hotfix branch for your original abandoned hotfix
cherry-pick the changes in from your copy of the original hotfix branch
continue where you left off in the original hotfix before the interruption.

Kind of counter to the whole idea of saving work by using git flow as a standardised branching strategy.

Multiple hotfixes for separate issues is a regular occurrence in production environments, and should be supported by the VC workflow. And indeed, the decision of which version number to release under should be postponed until the hotfix is merged in again. To ensure an urgent fix that was started after a less urgent one, but released before, ends up with a lower version number than the next release.

Jan 14 '16 10:01 jrial

👍

Jun 29 '16 12:06 dvalfrid

This is an important feature! Our company likes using the gitflow model, and we have a ton of different projects, and it's not uncommon that the need arises for multiple parallel hotfix branches when support tickets start rolling in. We've resolved to manual creation of branches as well as part of gitflow's workflow at times due to that! Please please pretty pretty please with a cherry on top - could we have multiple parallel hotfix branches, please?? It always seemed odd to us that we couldn't..

Oct 21 '16 06:10 Grinderofl

It's incredibly common for projects to maintain some number of legacy releases, and have a need to patch multiple past releases when a serious bug or vulnerability is found. I've tried to introduce gitflow to some teams I work with, and I agree with them that this is a must have feature before they can adopt it.