couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirkjan Ochtman <>
Subject Re: How to merge a feature branch into master
Date Sun, 10 Nov 2013 13:45:44 GMT
On Sun, Nov 10, 2013 at 2:07 PM, Andy Wenk <> 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).



View raw message