How do I position feature flags when moving from Gitflow to Trunk-Based?

Short answer: in Gitflow, painful merges and week-long releases come precisely from long-lived branches drifting. Trunk-Based fixes that by merging small changes to main continuously; but feature flags are what enforce “an unfinished feature on main can’t reach users.”

The issue: you want to merge code often, but you don’t want half-done work leaking to production. Flags bridge that contradiction.

1. Long-lived branches are the problem itself — remove them. feature/develop/release branches drift from main over time; conflicts and week-spanning releases are born right there. In Trunk-Based you merge changes to main continuously, in small chunks.
2. Keep unfinished work “dark” behind a flag. Put the incomplete feature behind a flag that’s off in prod, and still merge the code to main daily. When the feature is done and tested, you flip the flag. The code is live but invisible to users.
3. Flags decouple deploy from release. You deploy code whenever you want (deploy), and turn the feature on when it’s ready (release). This split also gives you per-flag canary/gradual rollout — you can open the same version to 5% of users and watch.
4. Discipline is mandatory: short-lived branches, strong CI, flag hygiene. Branches should live a day or two, and CI must run solid on every merge. Most critical is flag hygiene: clean up dead flags, or they turn into their own technical debt and muddy the codebase.

Bottom line: for a 20-person team aiming at Continuous Delivery, the right model is Trunk-Based + feature flags. I’d keep branches short, merge everything behind flags, and treat flags as temporary — removing them the moment a feature is done. When exactly, and under what preconditions, I move to Trunk-Based, I detail on sade.dev.