That's fair.. it really depends on the situation. Too many feature flags can get complicated in the same way too many open, long running branches can. It's nice

That's fair.. it really depends on the situation. Too many feature flags can get complicated in the same way too many open, long running branches can. It's nice to have the option of either. Feature flags I think are a bit easier to forget about and leave in the code; branches are obtrusive and you constantly have to merge new code in to keep them updated, pushing dev to get rid of them ASAP. All my work lately has been done in branches, which then merge to master, and master gets deployed to production as needed: sometimes immediately with a single bug/feature, sometimes several bundled together after a week or two. Depends on severity, other work occupying the team (especially QA), and which software/system(s) are affected (eg. core software, infrastructure, or internal tooling). I am pretty sure we've only used feature flags in the core software, and only a couple times. Of course, that software is hybrid cloud/on premise, and as such we have strong version numbering for every release, so features/changes naturally tie to the customer-facing release numbers.