search

petervanderdoes / gitflow-avh

AVH Edition of the git extensions to provide high-level repository operations for Vincent Driessen's branching model
http://nvie.com/posts/a-successful-git-branching-model/
Other
5.42k stars 527 forks source link

Question: How to add a third branch to the flow? #323

Open vzamanillo opened 7 years ago

vzamanillo commented 7 years ago

Hi!

Our team are actually working with a third staging branch, the staging branch have to include the same changes as feature, hotfix and bugfix branches.

How to include the staging branch into the flow? Is this possible? maybe using the post-flow-*branch*-finish hooks?

Any ideas or help is welcome.

Thanks!

petervanderdoes commented 7 years ago

Funny you ask, I just started a job where there is a same sort of setup. I'll have to think about this and how this can be implemented.

vzamanillo commented 7 years ago

@petervanderdoes , thank you!!

jbinnography commented 7 years ago

We have a similar set up at my job, and I've been thinking a lot about implementing something like this in my fork.

I'd love to help flesh this out.

vzamanillo commented 7 years ago

I asked for a third branch, but maybe should be easy to implement this feature for an "unlimited" number of branches (or limited but enough, 5 by example) it may be useful for other people who use, production, development, pre-production and test branches.

MeikTranel commented 6 years ago

This would help at modeling multiple future releases in planning as well, i assume? Not just for different stages of confidence aka staging/beta etc. ?

adamrodger commented 6 years ago

I'm looking to do the same thing. My plan at the moment is to remove the check that makes sure there's only one active release branch and then whenever a change is merged to a release/* branch, cascade that change through any 'later' release/* branches and then to develop.

That does assume that the branches can be ordered sensibly though. If you're using SemVer then that's the case, otherwise you'd need some way for the user to configure the order of the branches which sounds overly complicated.

For example, if you have branches release/1.2.1, release/1.3.0 and release/2.0.0 then it's easy to see how a change to 1.2.1 would go through 1.3.0 -> 2.0.0 -> develop.

At the moment I'm planning to implement that as a post-finish hook so that I can implement it easily locally without changing the gitflow code, but I could push that up as a PR properly if that sounds like a sensible approach.