Multiple Hotfix's

[paulc-momote]

Hi

We have a need to have multiple hotfix branches, at first I thought
this should be OK but on using git-flow I have noticed that there
appears to be a limit to only one hotfix branch at a time.

The reason for this is that we may have multiple fixes, some are more
urgent P1 level fixes and must go live ASAP. Others may be less urgent
and require more lengthy testing before they can go live. We therefore
need to have someway to keep these fixes separate from one another so
that we can be selective with what fixes go live.

On top of this at some point both/all fixes will need testing
together. Our initial thoughts where that we should then create
another hotfix branch from master and merge the other hotfixes into
this.

Is this making sense and if so does anyone agree/disagree or recomend
another strategy that may be better for our scenario?

Thanks,

Paul

[Ryan Cross]

Hi Paul, 

My guess is that you need to adjust the way you're working a bit, since by nature non-urgent hot fixes are not really hot fixes. They are fixes that should be put into the release branch or possibly into a separate branch. 

Also keep in mind, git flow is just a wrapper on standard git commands so you can use your own branches as well. 

-Ryan

[paulc-momote]

Thanks for your reply Ryan.

I entirely see your point, unfortunately we have some pretty complex
procedures around fixes and release drops that are not ideally suited
to our development style, this does sometimes mean that we have to put
less urgent fixes in without new features that may be on our
development and feature branches. However this is what the business
enforces!

I think we will try to stick to your recommendations where possible
but sometimes we just will not be able to and will have to revert back
to good old manual git commands.

Thanks again.

Paul

[Greg Froese]

Paul,
I run into similar situations, and I wrote an exhaustive description of what I need to do and who I intend to do it.
Maybe it will help you: http://groups.google.com/group/gitflow-users/browse_thread/thread/2da02b708de6a68/90ce2925ceb2d34f#90ce2925ceb2d34f
gf

[Ryan Cross]

Hi Paul, 

It also sounds like the concept of support branches might also be more inline with what you are trying to do. They have been implemented as an experimental feature in the new 2.x version, but still need some work. It should be relatively easy to review how that works and adapt it to your needs, or even possibly create your own fork with the necessary functions you need. 

-Ryan 

[paulc-momote]

Guys thanks for your replies.

The link to the post Greg provided certainly contains some food for
thought, though I'm wary of venturing to far from the standard git-
flow methods of working.

I dont think a fork is essential for what we are looking to achieve as
it can certainly be managed with regular git commmands. We will
certainly look into this though to speed things up and in case any of
this is useful to others in a similar situation.

I'll be sure to post back any updates hear.

Thanks again.

Paul

On Oct 27, 5:39 am, Ryan Cross <ryanecr...@gmail.com> wrote:
> Hi Paul,
>

[paulc-momote]

I forgot to mention also that we are already using support branches to
support legacy/alternative versions of the application. We could of
course create another support branch to support the main/production
release but I think from my understanding this would be missing the
point. Again I dont want to cause additional complication to the git-
flow process but would rather break it a little to avoid having to
hack around with it a lot.

Thanks again.

Paul