On Nov 1, 2012, at 11:29 PM, Eli Stevens (Gmail) <[email protected]> wrote:
> On Thu, Nov 1, 2012 at 9:28 PM, Adam Kocoloski <[email protected]> wrote: >> Hi Eli, Benoit linked to a variant of it in the beginning of this thread. >> There's a lot to like about it, and most of it is very similar to the >> workflow we're converging on in this project. The big difference is that in >> git-flow the HEAD of "master" is always the latest tagged release, and that >> "develop" is where the day-to-day completed work lands. > > I didn't realize it was a direct variant; the lack of an explicit > release branch seemed like a significant change in process (perhaps > appropriate for the poster's use case, but doesn't seem to fit what > I've seen of CouchDB). Agreed, I think the original git-flow is a better match for packaged software development. > Note that at my work we easily changed the > git-flow "branch 'master' is last stable release" and "branch > 'development' is integration for next release" defaults to be 'stable' > and 'master' respectively. Good to know. >> Personally I don't think I would coerce CouchDB into the nominal git-flow >> shape, but I thought I'd note the similarities in case others find the >> tooling really appealing. Cheers, > > As an outsider, aside from naming convention, it's not clear what the > mismatch is; care to expand? Of course, if this is getting off-topic, > feel free to let this part of the thread die. :) So, actually, I forgot one huge detail, which is that our git setup disallows merge commits on master! I was only reminded of it after the X-Couch-Id Pull Request was accepted earlier today. So I guess our conditions for branching and our naming of those branches are reasonably similar to git-flow, but the fact that those branches are rebased/squashed/cherry-picked/deleted instead of merged means we actually have a completely different workflow after all ;) Cheers, Adam
