I know there's been a lot of gripes against git-flow but I think one of the reasons it had such an impact is that project maintainers/leaders are looking for so

I know there's been a lot of gripes against git-flow but I think one of the reasons it had such an impact is that project maintainers/leaders are looking for some sort of "workflow" or process around git. As a project grows, you want some process around how to name branches, when to use tags, how to handle merges, from which branch to base your work on, etc. Git flow gave all the answers in an authoritative way. You could just say to junior team members/contributors that the project uses git-flow and send them the link to the doc. I applied git-flow to my projects but simplified the process, eventually abandoning almost all its principles. It did give me a starting point to think about what we really needed, what is important and how to communicate it with a team. One particular process I am quite fond of is to use the develop branch as a free for all integration/testing branch with automated deployment to a test (dev) environment with absolutely no guarantee of working whatsoever to any stake holder. This allows devs to demo their work, collaborate and spot conflicts early, without being slowed down by fear of breaking something or waiting for a code review. Unlike git-flow, that develop branch is a dead end. It does not get merged to master or any other branch ever and gets force-push (reset) when things go wrong. Feature branches eventually get proper code review, their history can be cleaned up and eventually merged (or dropped) via a proper pull request.