couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Wenk <a...@nms.de>
Subject Re: How to merge a feature branch into master
Date Sun, 10 Nov 2013 18:14:03 GMT
On 10 November 2013 15:11, Robert Newson <rnewson@apache.org> wrote:

> "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.


>From your feedback and my questions I conclude that we should make things
clear here and write it down. I would like to do that (I am writing a lot
of notes recently ;-) ).

My point of view now is probably the same Robert has. And this results
basically in the way Dirkjan described the process with:

> - 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

I am happy with that because it is basically the same I do with the
difference, that the described process fits better for big feature branches
where logical units are needed for understanding. The only thing I would
change is the order. I would first cleanup the feature branch commits and
then rebase the feature branch onto the current master resulting in:

> - create feature branch from master
> - work on feature branch
> - clean up feature branch commits
> - rebase feature branch onto current master
> - merge feature branch into master

Doesn't make that more sense? Or do I oversee something?

Cheers

Andy


>
> 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
>



-- 
Andy Wenk
Hamburg - Germany
RockIt!

http://www.couchdb-buch.de
http://www.pg-praxisbuch.de

GPG fingerprint: C044 8322 9E12 1483 4FEC 9452 B65D 6BE3 9ED3 9588

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message