What is your definition of "small"? The projects I worked on at ThoughtWorks for over three years numbered in the dozens of developers, all pairing, and all committing directly to master.
Your 2nd paragraph seems to be saying you dislike the git-flow model, but the 3rd suggests you like feature branching?
Anyway to add my 2c, we use hg-flow at work (git-flow for Mercurial), and it works well for us, because all our repos have a consistent feel to a new dev approaching them -- the 'develop/release/hotfix' streams convey a lot of meaning about the repo's state. Though I should point out we are a small team (<10 active devs), and rarely do we encounter bad merges when we finish our feature branches.
However I've listened to a few good podcasts lately about trunk based development [0] [1] and can see the advantages for large teams (as it forces people to deal with merges sooner, and keep code shippable, instead of deferring them to some nasty, big, future merge).
[0] https://devchat.tv/iphreaks/136-ips-efficient-engineering-pr... [1] http://theshipshow.com/2013/09/branching-merging-and-octopi-...
Ugh, such a false dichotomy. Does anyone actually think http://nvie.com/posts/a-successful-git-branching-model/ is a good idea?
Instead, compare to any one of hundreds of successful examples on github, all using feature branch based models.
Thoughtworks (and other consultancies that take the CD book to heart) would have everyone pair programming and committing directly to master. This simply doesn't scale beyond a small team. It also actively discourages collaboration across teams, because there is no process in place to review external contributions.