Phabricator's Recommandation on Branching Based on Strategy Used by Facebook

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?