On Nov 1, 2012, at 11:29 PM, Eli Stevens (Gmail) <wickedgrey@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 9:28 PM, Adam Kocoloski <kocolosk@apache.org> 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
|