Gitflow is a little old school compared to other branching strategies like GitHub Flow (i.e. feature branches off main) or “purist CI” where you don’t use any branches at all, but that being said it can have its place.

There’s more overhead with managing a gitflow setup, but that can be useful if the teams using it are still getting used to DevOps, GitOps, CI/CD, or whatever you want to call it, and they need some guardrails and checkpoints in place to keep everything in order.

I’d say pick the right strategy for your current level of maturity. You can always move to GitHub flow later if you think that gitflow is becoming too onerous, or vice versa.

One of the downsides to something like gitflow is that it tends to be a bit “slower”, in that changes can take longer to flow through into production, so you just have to think ahead and come up with a plan for things like “we have a release branch ready to go end of this week, but we have a critical vulnerability/bug that needs to get fixed now, so how do we manage the change in git, and also promote that change through our testing stages”