The main thing to keep in mind with git workflows is that one size does not fit all. The number of people working on the code, and the way they work on it, has a big impact on which git workflow works best for you. The nice thing about git is that it&#x27;s flexible enough to accommodate very different ways of working.<p>His primary objection to <i>git flow</i> seems to be integration hell, which is easily avoided by regularly pulling from develop, which is something you also need to do in his model. His point about git bisect is interesting, though I&#x27;ve never heard of anyone using it.<p>The primary advantage of shared feature branches is that multiple developers can work on the same feature that&#x27;s not ready for release yet, which is impossible if you&#x27;ve got a single shared branch, and it means others have easy access to your code if something happens to you. Code shouldn&#x27;t live just on the developer&#x27;s machine. And while other backup solutions exist, git can keep it in the regular developer work flow.<p>That said, I don&#x27;t think feature branches are sacred; I&#x27;m totally fine with developing small features straight on develop. Or master, if you prefer. Whether you want master to be stable or unstable is a matter of taste. Although I personally think it&#x27;s useful to have a single branch that always contains the latest stable release.