My work in git, to this point has been simple enough: everything goes into master. Other people have much more complicated versioning requirements. And it seems not everyone can agree on how to handle versioning.
A while ago, I came across Vincent Driessen's branching model, aka 'git-flow' as described by Jeff Kreeftmeijer. It appears to be a 'feature branch' mechanism of tracking differing time lines, features, and code sets for code development. It seemed complicated, but also seemed to cater to functionality.
Today, I came across a differing view: Three-Flow, a different successful git branching model devised by Rod Hilton. It conforms to my idea of keeping most everything in master, keeping divergences merged back in to master, and letting minimal stuff stay out on candidate or release branches. The candidate branch fits nicely into a 'test phase', with the release being 'green to go'.
In either scenario, there are some 'complicated' commands to learn, but that would be part and parcel of a flexible version control system.
2017/09/20 - because there was no other place to put this, something tangentially related: Pull Request Based Development Sucks - but the consensus isn't quite so cut and dried. The comments have interesting points about the positives of peer review, how to write commit statements (why vs how), and some thoughts on really how to handle pull requests.
2018/02/04 - Branch By Abstraction instead of by branching in source control.