I used to use something like git flow, but the long-lived dev branch proved to be a real problem for QA because it changes constantly which led to tester confus

I used to use something like git flow, but the long-lived dev branch proved to be a real problem for QA because it changes constantly which led to tester confusion and wasted time. What I do now is keep master always release-ready and work is done in feature branches. The feature branches each automatially get their own (numerous) builds for testing, and internal QA is done against those. QA can be held up for weeks or months, so doing it this way keeps unfinished code out of releases and allows the business to change their priorities to shelve stuff that's suddenly not as urgent as it was last week - and also to suddenly do new surprise submissions/releases the day after randomly promising them in a phone call. If two feature branches have overlapping changes and it's taking people months to approve them then the merges are annoying, but usually sorted out in the lifetime of a single cup of tea. Release builds are done off tags, usually on master. Hotfixes to old releases (when there's no QA resource available to test a big update) can be done in a low-impact way by branching ("zombie/customer-platform-x.y.z") off the tag for that release, cherry-picking onto it and adding a release tag. Customers get demo/QA builds, also done off tags so when they get around to reporting an issue weeks later we know what code they've been looking at. (For context, the software is a client-side white label thing with different builds targeting multiple platforms - so there's a customer/platform matrix meaning many different releases, and almost every release has to be a manual submission each involving different 3rd-party QA which takes 2-6 weeks (best case, with no issues found). Config + content is dynamic, no two customers use the same subset of functionality. Keeping everything current is impossible.)