Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Support multiple concurrent release/hotfix branches #3

Open
nvie opened this Issue · 16 comments
@nvie
Owner

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
Owner

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 baby-gnu referenced this issue from a commit
Daniel Dehennin Support multiple concurrent hotfix branches
This is my implementation of the multiple hotfix for #3

* git-flow-hotfix (require_no_existing_hotfix_branches): Removed.
  (cmd_start): Remove call to require_no_existing_hotfix_branches().
42a81bd
@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.

@lpanebr

+1 for multiple hotfix branches concurrently.

@ghost

+1 is important feature!

@stinoga stinoga referenced this issue from a commit in stinoga/gitflow
@stinoga stinoga Support for multiple hotfixes via gitconfig. Issue #3 a15c850
@stinoga

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

[gitflow]
hotHot = true

@lmartins

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

@phlawski

+1 for multiple hotfix branches

@bitslasher

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.

@elistevens

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

@travisdmathis

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.