Feature flags vs long-lived branches

Published 21 October 2026

You are building a new checkout that will take three weeks. Users must not see it until it is done. There are two ways to hide it.

A long-lived branch keeps the new code out of main until it is finished. Your work sits on feature/new-checkout for three weeks, then merges in one go.

A feature flag lets the new code merge into main every day, deployed to production but switched off. An if around the new path reads a setting at runtime, and the setting decides who sees it: nobody, your team, 1% of users, everyone.

Both hide unfinished work. They differ in when your code meets everyone else's. With a branch, that happens once, at the end, all at once. With a flag, it happens every day, a little at a time.

Why long-lived branches hurt#

While your branch lives, main keeps moving. After three weeks, a busy team has merged hundreds of changes you have never run with yours. Merging is then a big conflict resolution session, in code other people changed for reasons you do not know, and the tests that pass on your branch say little about how it behaves on top of everything else. On a remote team this is worse: the person who wrote the conflicting change is asleep while you resolve it.

In 2010 Vincent Driessen published GitFlow, a popular model with long-lived develop and release branches. In 2020 he added a note to the top of his own post, saying that for web apps that are delivered continuously, he would recommend a much simpler workflow instead. GitFlow still fits software that ships numbered versions, like a library or a desktop app.

Trunk-based development#

The alternative is trunk-based development: everyone merges small changes into main (the trunk) at least daily, and branches live for hours or a day or two, never weeks. Google has worked this way in one huge repository for a long time. It is what makes CI mean something: you cannot integrate continuously with work hidden on a branch for a month.

Unfinished work stays hidden in one of two ways:

• Branch by abstraction: put an interface in front of the old code, build the new version behind it piece by piece, then switch over. No flag service needed.
• A feature flag: the new code path is in production but switched off, and you switch it on for more people as confidence grows.

Deploy is not release#

That is the real power of flags: deploying (putting code on servers) and releasing (letting users see it) become separate decisions. Deploys happen many times a day and nobody notices. Releases happen when product is ready, to whoever you choose, and undoing one is a switch, not a deploy.

Ship the same buggy checkout both ways and compare.

Pete Hodgson's article on Martin Fowler's site sorts flags into four kinds, and they have very different lifetimes:

• Release flags hide unfinished or untested work. Days to weeks, then delete.
• Experiment flags split users for an A/B test. Live as long as the experiment.
• Ops flags, or kill switches, turn off an expensive or risky feature under load ("disable recommendations if the database is struggling"). Can live for years, on purpose.
• Permission flags turn features on for some users: a paid plan, beta testers, staff. Long lived, and really part of the product.

How flags are built#

Most teams use a flag service rather than a config file, because changing a config file means a deploy. The service holds the rules ("on for staff, and for 10% of users in India"), and an SDK in your app evaluates them. OpenFeature, a CNCF project, gives you one API in front of any vendor, so switching from one flag service to another changes one line.

import { OpenFeature } from '@openfeature/server-sdk'
 
// The provider is the only vendor-specific line: LaunchDarkly, Unleash, Flagsmith...
await OpenFeature.setProviderAndWait(new YourFlagProvider({ sdkKey: process.env.FLAGS_KEY }))
const flags = OpenFeature.getClient()
 
export async function checkout(req) {
  const useNew = await flags.getBooleanValue('new-checkout', false, {
    targetingKey: req.user.id, // same user, same answer on every request
    country: req.user.country,
  })
  return useNew ? newCheckout(req) : oldCheckout(req)
}

Four details in that snippet matter in practice:

1. The default (false) is what happens when the flag service is unreachable. Make it the safe, old behaviour.
2. The targeting key keeps users sticky. A user hashed into the 10% stays there, instead of flickering between old and new checkout on every page.
3. Evaluation is local. Server SDKs download the rules and keep them in memory, updated by a stream or a poll, so checking a flag costs microseconds, not a network call.
4. Both paths are tested. While the flag exists, CI runs the important tests with it on and off, because production has both.

In the interview#

Checkpoint#