Git flow and parallel release branches

[rich....@coveros.com]

I've got a dilemma with my current project. I'm trying to introduce Git Flow, but there's an adamant demand to support parallel, simultaneous release branches. This implies (requires?) that there's no real "mainline" for the develop branch to follow. It also means that new feature branches would be created/merged back into the "release" branches, as opposed to from a normal "develop" mainline. Effectively, I need _multiple_ "develop" branches to exist at the same time. I want to support feature creation and completion from those branches.

I've considered using Git flow "release" branches to support this, but they don't really seem designed to support that methodology.

I've scoured Google looking for suggestions on how to do this. As much as I'd love to just say "stop doing parallel development," the bureaucracy and team structure of my project isn't willing to bend in that direction, yet.

Has anyone else had experience using Git Flow to support parallel release branches?

Rich

[Bill Ward]

I would just have two release/xxx branches going. git-flow doesn't like you to do that (when you do "git flow release start" for the 2nd one you get an error) but you can get around that by doing it in a separate clone (with a shared upstream of course).

How are these two parallel releases kept in sync with each other? Which one goes to production? Is this for the upcoming + the next release? Is your product something you ship to customers so you have to maintain backports or is it like a hosted website where there is just 1 production version?

--
You received this message because you are subscribed to the Google Groups "gitflow-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gitflow-user...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Check out my LEGO blog at brickpile.com
Follow/friend me: Facebook • Flickr • Twitter • LinkedIn

[Henrik Johansson]

Generally a bad idea afaik. Why do they want this?

[Peter van der Does]

I suggest using Support branches for this. Create a Support branch for a given release and you are good to go.

Using git-flow AVH Edition you can start a feature branch from any branch, so also from a support branch. When you finish such a feature it will be merged back into the base branch it derived from.

Disclaimer: I'm the project lead for git-flow AVH.

P.S. Debian and Ubuntu both use git-flow AVH as the source for their package git-flow.

P.P.S. I don't think parallel development is that uncommon. git itself maintains "older" versions, When they released Git v2.5.2 they also released updates to older maintenance tracks, v2.4.9, v2.3.9 and v2.2.3

[Henrik Johansson]

No maintaining patches for older releases is one thing but it sounded like they wanted multiple "next releases" which, while everything can be made to work, seems needlessly complicated.

--

[Bill Ward]

Can anyone explain why git-flow (non-AVH) doesn't like having multiple release/* or hotfix/* branches?

[Peter van der Does]

Only Vincent Driessen can truly answer this question of course, as he created the initial version of git-flow.

As far as release branch I can think of a reason: The release branch is a intermediate branch between development and production. I always see a release branch as a staging area. In general you won't have multiple different staging area's for on e product.

For the hotfix, well I don't really know. What I can think of is when you are not working in a team you want to finish what you start first or the thought process of if somebody is working on fix A and another person works on fix B they could interfere with each other. I believe hotfixes were set up to be for service interrupting problems and nothing else.

But again, I wasn't involved in the initial setup of git-flow :)

Peter

[Eugen Martynov]

I would release faster. I don't understand why release delaying is solved on the source branching layer.

[Dzmitry Lazerka]

I'd also suggest to review your release cycle. Half a year ago we also spent weeks preparing the next version for release (it's a mobile app), but we changed that, so now we release as often as possible, sometimes several times a day. Testing automation helps a lot, although it's kinda hard with mobile apps. And also small bugs are considered ok, because now we fix them in a matter of hours. Management is happy to see new features faster, developers are happy to have only one "current" version to maintain.