What branching strategy would you recommend, and what would make you choose a different one?

My default for a team on a scheduled release cadence is short-lived feature branches merged into a mainline through reviewed pull requests, a release branch cut per release so it can stabilise while development continues, and hotfix branches taken from the release tag and merged back into both the mainline and the release branch.

I would move to trunk-based development with feature flags if the team were genuinely doing continuous delivery — small changes, strong automated coverage, the ability to ship several times a week. Trunk-based development with weak test automation is just a single shared branch with a better name.

What would make me choose differently: how long features take relative to the release cadence, how much automated regression exists, how many teams touch the same metadata, and whether the org's release obligations require a stabilisation period. A team whose features take six weeks against a monthly release will suffer with any strategy until the features get smaller.

The two things I care about more than the strategy name are that branches are short-lived and that the back-merge from hotfixes is enforced. Long-lived branches guarantee a painful merge at the worst possible moment, and a hotfix that is not back-merged is a regression scheduled for the next release.