[nerdwaller]

I think it really depends on what you’re developing and delivering. Master based development is great for end-user deliverables (web apps being the big one that comes to mind, many libraries could do this too). But if you’re writing a language or LTS releases I could see a pretty good case for a branching model like git-flow.

My experience with a work using gitflow is similar to yours, it was very messy and hard to manage. It was even worse that those driving it didn’t really know much about git so 95% of the commit messages were “Merged X into Y...” instead of using a more linear history.

[kostarelo]

> It was even worse that those driving it didn’t really know much about git so 95% of the commit messages were “Merged X into Y...” instead of using a more linear history.

How so? Why merge commits are bad? Are you suggesting of rebasing each topic branch or commiting directly to the master?

[damnyou]

Merge commits are bad because they add unnecessary complexity. Your software is already complex enough. Why add complexity to your commit logs and your overall development process?

A linear history is easy to manage and easy to understand. It might be slightly worse for people committing code, but developers read several orders of magnitude more code than they write. Always optimize for reading code over writing it.