

Phabricator's Recommandation on Branching Based on Strategy Used by Facebook - chengyinliu
http://www.phabricator.com/docs/phabricator/article/Recommendations_on_Branching.html

======
chengyinliu
Not using feature branch at all is something new to me. Our current strategy
is closed to the one Vincent Driessen described in his [blog
post](<http://nvie.com/posts/a-successful-git-branching-model/>).

I am not clear on if it is actually better to not use feature branch. The
article gave a couple of reasons:

1\. You don't have to do merges. 2\. Risk is generally spread out more evenly
into a large number of very small risks created as each commit lands. 3\. You
can test interactions between features in development easily. 4\. You can A/B
test and do controlled rollouts easily.

I do agree with 1, 2 and 3. However, I am not sure how to weigh them. One
scenario worries me about everyone developing on development is what if
someone break development? Admittedly, we need a large test coverage for it,
but feature branch isolates each develop group nicely and minimize the risk of
one group being interrupted by the other. For reason #4, I don't see how it is
a clear advantage. I think there is a way to do the same with feature
branches, as long as the developer keep both version on the branch.

I'd like to hear your opinions on this. More over, it sounds to me that with
this branching modeling, a variety of systems (e.g. GateKeeper) needs to be in
place. What exactly are those systems?

