couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: [DISCUSS] Git workflow
Date Mon, 29 Apr 2013 19:25:19 GMT
yes, merge, don't cherry-pick. We'll only cherry-pick to backport fixes.

so, rebase before merging, but don't squash. We'll get ff merges for
single item branches and 'proper' merges for multiple item branches,
which sounds like what we're agreeing on.

I'd say development is on fix- and feature- branches, merging to
master when complete. I don't see what a 'develop' branch adds besides
complexity and anyone that's read this whole thread will be
overwhelmed by complexity already.

B.



On 29 April 2013 20:01, Randall Leeds <randall.leeds@gmail.com> wrote:
> On Mon, Apr 29, 2013 at 6:59 AM, Robert Newson <rnewson@apache.org> wrote:
>> Bah, I meant:  I'm +0 on single commits merging from topic to master withOUT
>> a merge commit.
>>
>> On 29 April 2013 14:58, Robert Newson <rnewson@apache.org> wrote:
>>> Ok, my proposal is #1 from my original post with the refinement from
>>> Randall which I think we can distill as "you must not flatten a commit
>>> set". If your topic branch is best represented as >1 commit, then it
>>> must land on master as a merge commit. The other way to say it is that
>>> no topic branch is partially merged; it must be atomic. This means
>>> that branches, typically bug fix branches, which are naturally a
>>> single commit will simply fast forward. I'll let Randall respond to
>>> that point. I'm +0 on single commits merging from topic to master with
>>> a merge commit.
>
> -0 on single commit branches being merged with --no-ff. I think you're
> right: there's no reason to turn 1 commit into 2 just to have the
> merge commit in the log. In that case, the single commit serves as its
> own merge.
>
> It's probably still better to merge it rather than cherry-pick if it's
> been sitting in a branch while master moved ahead. There's tooling
> around visualizing which branches are merged or not (e.g., git branch
> --merged). Github makes this apparent in their branch UI. This is
> helpful for cleaning up old branches.
>
> Do we still need to decide on develop/master/1.X.Y stuff? Will we have
> a develop branch or just master?

Mime
View raw message