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](<a href="http://nvie.com/posts/a-successful-git-branching-model/" rel="nofollow">http://nvie.com/posts/a-successful-git-branching-model/</a>).<p>I am not clear on if it is actually better to not use feature branch. The article gave a couple of reasons:<p>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.<p>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.<p>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?