> This branching model is a direct mapping between regular run-of-the-mill release processes for applications intended to be delivered and installed by the general public, and how Git implements branches.

Git-flow kinda works for only one model, in which you have a single release out to the world at all times. If you have multiple concurrent supported releases, like Windows 2000/XP/Vista, or Chrome stable/beta/dev/canary, this model does not work.

The `master` branch and short-lived release branches in git-flow are a complicated dance and a lot of merging without much clear benefit. Compare with a trunk-based model:

* new features go into main branch (from feature branches)

* when making a big release, create a branch like release/23.09, do whatever preparations and testing you need, and release 23.09.0 - tag the commit that the release is built from

* bugfixes go into main branch (from feature branches) and then are cherry-picked into release branches (hopefully via pull requests)

* if the bug exists in release/23.08 and release/23.09, we can fix both and release 23.08.x + 23.09.y simultaneously

This model is much easier to comprehend, has less branching, and allows maintenance for older versions.