[QuiCasseRien]

This is the type of diagram that horrified me.

It's a very very hard and time consuming task for dev to maintain hotfix for previous releases !

Yeah, easier for users, they don't have to care about breaking changes or migration guide. They just blindly update to the nearest minor.

But as the time goes on, the code for dev ends up being a complete mess of git branches and backports. Dev finally forgot some patches and the software contains a major security hole.

Dev ends by being exhausted, frustrated by its project and roasted by its users.

=> What I do : do not maintain any previous release but provide a strong migration guide and list all breaking changes !

users just have to follow updates or use another software.

I'm happy with it, my project has no debt code and more clean code.

[ryukoposting]

Yes, the original git-flow post aggregates several widely-held intuitions about git, and then shoves a bunch of fluff in the middle to make it look more appealing to middle management.

I have seen firsthand how the original git-flow post convinced management to move off SVN. In that regard, it's an extremely important work. I've also never seen git-flow implemented exactly as described.

...and frankly, there are better ways to use git anyway. The best git workflows I've seen, at small scale and large, have always been rebase-only.