[jacobparker]

> I thought it was a weird, over-engineered solution to a non-existent problem.

To be fair, its a cookie-cutter approach that resonates with people unfamiliar with git but not ready/willing to invest the time to understand it deeply. That is understandable; a lot of people come from other systems and just need to get going right away and gits poor reputation for command-line consistency etc. is well-earned.

(To be clear, I am not a fan of git flow.)

If anyone is interested in truly understanding git, start here: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

[matthiasv]

His point is that this cookie-cutter approach is more complex to the development model he presents (and is in fact pretty common among open source software). You don't need to understand Git deeply to realize that master is stable and merges in finished and cleaned up features.

[jacobparker]

I should have been more clear - I agree that its more complicated. My point was that regardless, it seems to resonate. I believe its because the complications look useful at a glance and layering a rigid model on top of git frees you from having to consider its full scope of possible operation.

(I believe that git flow is definitely better than "everyone does things their way", and that's one competing "rule-book" for a team new to git.)

I'm pretty confident that understanding the tool better will help you to judge how to use it more effectively. The best way to understand git is to understand its data-model.