There is no one-size fits all branching model for git. But they are extremely important. Some people swear by gitflow and others don't. I wish there was a set

There is no one-size fits all branching model for git. But they are extremely important. Some people swear by gitflow and others don't. I wish there was a set of tried ones though, with some simple questions to help decide. I can think of two questions: First ask whether you need to be supporting multiple versions in production or not. A simple web service with single tenant model would do OK with just one maintained version. There is always a "current" latest production release and whether that branch it's built from is called "production" or "master" doesn't really matter. You have a stable main, and then unstable branches are develop and feature. But if you must support multiple production versions longer term, as for any software that is installed by clients (Desktop, self hosted web backends, ...) then of course having a single "production" branch no longer flies. You need to have long lived release branches, that might even diverge and never merge back to any long term development branch. These could be called "release/v1.0" or similar. And obviously if you have designated release branches then there is no point having an unstable develop branch - you can just make main your unstable develop branch. Second after deciding between maintaining 1 or N active versions in production is deciding whether you can do continuous deployment. If you can deploy to production multiple times per day, that might affect your branching model. If on the other hand you have fixed waterfall-like deadlines because e.g. you only have a chance to get regulatory review for the new version (if you make security critical software e.g. medical, automotive) twice per year then that might have an effect on your branching model, you'd then use your release/v1.0 branches before the release as a long term stabilization before the release.