Support multiple concurrent release/hotfix branches about gitflow HOT 38 OPEN

@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.

from gitflow.

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.

from gitflow.

Hello. It is implemented in gitlow-avh, packaged in my Debian:

https://github.com/petervanderdoes/gitflow-avh/blob/develop/git-flow-hotfix#L208

Regards.

from gitflow.

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.

from gitflow.

@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.

from gitflow.

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?

from gitflow.

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

[gitflow]
hotHot = true

from gitflow.

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.

from gitflow.

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.

from gitflow.

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.

from gitflow.

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.

from gitflow.

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

from gitflow.

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)

from gitflow.

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.

from gitflow.

@spiffytech +1

from gitflow.

+1 for multiple hotfix branches concurrently.

from gitflow.

+1 is important feature!

from gitflow.

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

from gitflow.

+1 for multiple hotfix branches

from gitflow.

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.

from gitflow.

👍

from gitflow.

Another not ideal way is to simply rename the hotfix branch

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

from gitflow.

👍

from gitflow.

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..

from gitflow.

Just adding myself to the other folk who really want this feature (well really it's a removal of the check for one existing, I assume).

from gitflow.

Awesome work guys

from gitflow.

👍

from gitflow.

👍

from gitflow.

👍

from gitflow.

👍

from gitflow.

👍

from gitflow.

👍

from gitflow.

+1 for multiple release and hotfix branches.

from gitflow.

+1

from gitflow.

+1

from gitflow.

+1

from gitflow.

+1

from gitflow.

+1

from gitflow.