I prefer the concept that master should always be deployable to production.  My CI creates a build artifact on every commit to master and the artifact can be deployed to staging&#x2F;production at any time.  Thus, master should always be considered stable.<p>Development should happen in a branch.  When it&#x27;s done, checkout master LOCALLY, merge in your branch, run unit tests, if tests pass, push master.  If tests don&#x27;t pass, reset master back to origin and keep working on your feature.<p>This way master is always ready to go and you also get the benefit of seeing how a feature was developed and the merge commit is a representation of a complete chunk of work.<p>If you do need to back out a feature, how would you do it on a rebased, fast-forward merge?  You have NO CLUE where the start of the feature was.  You have to just guess based on the author maybe?  In my experience, I&#x27;ve never used git bisect so I don&#x27;t optimize my branching model for that experience.  For me, backing out bad merges is much more common so I optimize for that.