
Why does Martin Fowler not understand feature branches - DanielRibeiro
http://jamesmckay.net/2011/07/why-does-martin-fowler-not-understand-feature-branches/
======
quarterto
_If you check in code that breaks the build, then go home, and then someone
else checks it out, they can’t get anything done till you return and fix it._

A problem that Jenkins Build-per-Branch¹ nicely obviates.

¹<http://entagen.github.com/jenkins-build-per-branch/>

------
arohner
While I agree with the author that feature branches are useful, I think he
went too strongly the other way, against feature toggles.

Feature toggles allow you to do things like: 1) deploy only to certain users.
2) incrementally deploy to N percentage of your users. i.e. deploy to 1%, then
10%, then 100%. These are things that absolutely cannot be done by your VCS
system.

If you're going to use FTs, then yes, they need to be baked in and well
supported by your app. A consistent API & tooling are a good idea.

FWIW, at CircleCI (<https://circleci.com>), we use feature branches all of the
time. We automatically CI all branches, and we use feature toggles. In fact,
I'm toying with the idea of a feature-toggles-API-as-a-Service.

------
philwelch
I can't imagine how people do continuous integration _without_ feature
branches.

~~~
benjiweber
Feature branches are almost the opposite of continuous integration. If you're
committing to a branch then by definition you're not integrating your changes
with people working on other branches.

It's quite possible to integrate and deploy changes to production several
times a day. If it hurts, do it more often. Smaller changesets are far easier
to merge.

~~~
philwelch
OK, let me throw this out there: what if you're developing a feature that
takes longer than a fraction of a day to write, and you want that feature to
be developed independently of any other half-baked features that are out
there?

Or developing more than one feature at a time?

Or you are halfway through developing a major feature when you suddenly
realize there's a high-priority bug that has to be fixed first?

Or you decide halfway through developing a major feature that you went about
it all wrong and made a hash of everything and want to start from scratch?

> If you're committing to a branch then by definition you're not integrating
> your changes with people working on other branches.

When other people's changes are merged to integration, I'll rebase off of
integration and resolve any conflicts then and there. No problem.

> Smaller changesets are far easier to merge.

...and since I'm continuously rebasing off of the integration branch, all my
merges are fastforward, which is even easier.

The criticism against feature branches makes sense if it's coming from people
who don't use Git fluently. Otherwise it's absolute nonsense.

