AI-native
Feature flags vs feature branches: which should you use?
Use both, for different jobs. Keep git branches short, one per small change, merged the same day. Use a feature flag to keep unfinished or risky work switched off for users until it's ready. The branch moves code; the flag decides who sees it.
Updated November 11, 2026
How do feature flags and feature branches differ?
Both keep unfinished work away from users. They do it in different places. Flagger.gg's guide to trunk-based development with AI agents compares them:
| Feature branch | Feature flag | |
|---|---|---|
| Where unfinished work lives | On a branch, outside main | On main, deployed, switched off |
| When it merges | When the feature is done | As soon as each small change passes review and CI |
| Conflicts | Grow the longer the branch lives | Small, because every change merges quickly |
| Going live | A merge and a deploy | A flag change, in seconds, for chosen users first |
| Undo | A revert commit and another deploy | Turn the flag off; no deploy |
Why do long-lived branches break down with AI agents?
Several agents working at once on long-lived branches means stale branches, painful merges and big changes nobody can review well. When each agent merges small changes to main and hides unfinished work behind a flag, merges stay small and reviewable, and the flag decides when customers see the result. See running many coding agents in parallel.
Do flag-based teams still use branches?
Yes, short-lived ones. Each small change gets its own branch and pull request, merged the same day after review and automated checks. The flag, not the branch, holds back what isn't ready. That's how North Bay Ventures works: every change goes through a pull request, merges itself once the checks pass, and goes straight to production. Read how we build companies and feature flags instead of staging.
When is a long-lived branch still the right call?
When the change can't be hidden behind a switch, such as a large rewrite that touches everything, or work that must never reach production even switched off. Even then, keeping the branch short and merging often reduces the pain. For most product work, a small change behind a flag is easier to review and easier to undo.
How do you keep flags from piling up?
Remove each release flag once its feature is on for everyone and stable, in a small follow-up change. Declare flags in code so a stale one is easy to find; see keeping AI-written code behind declared flags. Kill switches for features that can fail are meant to stay. For the basics, read what a feature flag is.
Frequently asked questions
Are feature flags a replacement for git branches?
No. Teams still use short-lived branches and pull requests; flags replace long-lived feature branches as the way to hold back unfinished work.
Is it safe to merge unfinished code to main?
It is when the code is behind a flag that's off, and the flag can be turned off again in seconds without a deploy.
What is trunk-based development?
Merging small changes to one main branch at least daily, with unfinished work hidden behind feature flags.
Which is easier to undo?
A flag. Turning it off takes seconds with no deploy; undoing a merged branch needs a revert commit and another deploy.