Re-reading my last mail I'm afraid that I did a poor job with explaining of what is going on in my head. I hope that this little follow-up helps.
To me a typical gitflow usecase is to make development on the develop branch. Larger portions of features should be done on feature branches that branch from the develop branch, This should (in theory) allow better parallelization between teams but is only applicable when the changes made to complete the features do not overlap in the codebase. When a feature is complete it will be integrated back into the develop branch and the named feature branch would be removed. Note that at any time the develop branch would remain rather stable and could be shipped in a release. So when the decision is made to ship a new release, a release branch is created to have a place to stabilize the codebase and prepare things for the release. When that process completes the product would be ready to ship. Then the head of the release branch is tagged and the named release branch can be removed. Of course this does not prevent people from having multiple release branches concurrently. This for instance could happen when translations take longer than expected. :-) 2017-05-19 23:26 GMT+02:00 Dominik Psenner <[email protected]>: > If I understand the usecase correctly, then there should be these branches: > > * master > * release/4.4.1.x > * release/4.4.2.x > > Note that there could be even more branches if "unstable" development > continues on the develop branch or a bugfix branch is needed to create a > bugfix on a released (i.e. tagged) revision. Surely merging becomes overly > complicated when doing development in multiple release branches and > development at once, but that's in my eyes not an issue of the branching > model and it needs to be addressed somewhere else. > > 2017-05-19 23:01 GMT+02:00 Gary Gregory <[email protected]>: > >> Howdy, >> >> Thank you for the link. >> >> This is fine until you want to manage more than once major version in one >> repo, right? >> >> Over at HttpComponents, we have decided for now to keep to one repo, as >> opposed to one repo per major version. >> >> So ATM for example in HttpComponents' HttpCore we have a 4.4.x and master >> branch that are BOTH going to be used for releases. >> >> How do you deal with that in Gitflow? >> >> Gary >> >> On Fri, May 19, 2017 at 1:10 PM, Dominik Psenner <[email protected]> >> wrote: >> >> > Hi, >> > >> > would we like to use gitflow for our named branches? [1] >> > >> > [1] https://datasift.github.io/gitflow/IntroducingGitFlow.html >> > >> > Cheers >> > -- >> > Dominik Psenner >> > >> >> >> >> -- >> E-Mail: [email protected] | [email protected] >> Java Persistence with Hibernate, Second Edition >> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl? >> ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&link >> Code=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >> >> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >> am2&o=1&a=1617290459> >> JUnit in Action, Second Edition >> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl? >> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&link >> Code=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >> >> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >> am2&o=1&a=1935182021> >> Spring Batch in Action >> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl? >> ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&link >> Code=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Bli >> nk_id%7D%7D%22%3ESpring+Batch+in+Action> >> <http:////ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l= >> am2&o=1&a=1935182951> >> Blog: http://garygregory.wordpress.com >> Home: http://garygregory.com/ >> Tweet! http://twitter.com/GaryGregory >> > > > > -- > Dominik Psenner > -- Dominik Psenner
