couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: How to merge a feature branch into master
Date Sun, 10 Nov 2013 14:11:11 GMT
"I would agree with Jan/Dave that squashing branches to one commit is
undesirable. On the other hand, I would also say that keeping all the
commits on the feature branch as you created them is probably bad
form."

Absolutely, neither of those ideas are sensible. What we do at
Cloudant is, at the completion of a code review, to transform the
commits on a branch into logical distinct commits before we merge (and
most pull requests start as multiple commits). That is often a single
commit (the original one squashed with several follow-up tidying or
bugfixing commits) but is sometimes several. Each should be
self-contained and readable (though they do not have to be standalone)
and the set of them should achieve the goal.

It is as wrong to obscure the nature of your change by collapsing too
far as it is wrong to preserve, forever, all "oops, whitespace" and
"oops, typo" commits you added to your feature branch while hacking.

B.


On 10 November 2013 13:45, Dirkjan Ochtman <dirkjan@ochtman.nl> wrote:
> On Sun, Nov 10, 2013 at 2:07 PM, Andy Wenk <andy@nms.de> wrote:
>> - create feature branch from master
>> - work on feature branch
>> - rebase the work on the feature branch into one commit
>> - rebase master into feature branch
>> - checkout master
>> - merge feature branch into master
>>
>> I know there are many ways to do this task and believe me I had many many
>> discussions on that. What I want to know, is how it is done here and then I
>> will follow the way.
>
> I think we have an open issue to decide on our git workflow, that we
> keep putting off for some stupid reason. So if you want to help us
> pull through that discussion and get to something well-defined, that
> would be great. ;)
>
>> I discussed Jan's commit 659699de with Dave and understood, that all
>> commits from the feature branch are still there and on top is a info merge
>> commit with all messages. So that's the way it should be?
>
> I would agree with Jan/Dave that squashing branches to one commit is
> undesirable. On the other hand, I would also say that keeping all the
> commits on the feature branch as you created them is probably bad
> form. My ideal feature branch is something like this:
>
> - create feature branch from master
> - work on feature branch
> - rebase feature branch onto current master
> - clean up feature branch commits
> - merge feature branch into master
>
> Where "clean up" means that I end up with commits like this:
>
> - clean up whitespace in code area
> - minimally complete refactoring #1
> - minimally complete refactoring #2
> - minimally complete refactoring #3
> - actual feature/fix, part #1
> - actual feature/fix, part #2
>
> Where each refactoring is a chunk of change that is coherent by
> itself, helps me towards making the feature or fix, and doesn't break
> the build by itself. This is often easy, but can be hard or even (in
> edge cases) impossible.
>
> The other thing we'd need to discuss is how to deal with maintaining
> both master and maintenance branches. That issue has mostly been
> solves by the fact that we don't really do bugfix-only releases
> anymore in the current release schedule, but in the event of, say, a
> security release, it would have my preference to land security/import
> bug fixes on the oldest maintenance branch first, then merge it
> forward into newer maintenance branches/master (e.g. prefer merging --
> but only forward -- over cherry-picking).
>
> Cheers,
>
> Dirkjan

Mime
View raw message