Vincent Driessen's "A successful Git 1,932 branching model" (January 2010) keeps two permanent branches: main holds only released versions, one tagged merge per release, and develop collects finished features. Around them live three kinds of temporary branch: feature/* from develop, release/* cut from develop to stabilize a version, and hotfix/* cut from main for an urgent fix. Release and hotfix branches merge into both permanent branches, which is where most of the model's bookkeeping, and most of its merge conflicts, come from (17).
The model suits software that ships numbered versions on a schedule and supports several at once: desktop applications, firmware, libraries, on-premises products. For continuously deployed web applications it is overhead, as Driessen's own March 2020 note on the article says, recommending GitHub flow instead. The original git flow extension and its gitflow-avh 5,445 fork are unmaintained; Tower 122,436 's Go rewrite, git-flow-next 453 (github.com/gittower/git-flow-next (https://github.com/gittower/git-flow-next 453 )), automates the same ordinary git switch, merge and tag steps.