My biggest problem with &quot;A successful Git branching model&quot; is that it scares people into thinking they have to design and commit to a workflow before they can develop software.<p>Having a defined workflow is not a bad thing.  And it certainly wasn&#x27;t the intention of the author for anybody to stagnate.  Unfortunately, it&#x27;s very natural for technical people to overthink and over-engineer process.<p>In my mind, when an organization is new to source control or is haphazardly using it, it&#x27;s best to simply start using the tool.  Each product is different, each organization is different, and each developer is different.  You should mature into an organized development model based on what you know about your own situation.<p>If you develop on the develop branch and release on the master branch, but don&#x27;t communicate that clearly to the new guy, I guarantee he&#x27;s going to start working on master right out of the gate.  The same goes for every model where there&#x27;s a lack of communication around procedures and no workflow controls.<p>Git saw a rise in popularity because it was easy where every other solution was difficult.  If you&#x27;re having issues with code review, patches, release versioning, or whatever - address that particular problem.  If the problems are multiplying to the point where it&#x27;s significant, it&#x27;s time to think through a process.  Spending your time and energy ferreting out a process based on the fear of what might one day happen will result in a significant amount more time spent doing that then addressing the would-be problem in the first place.