Long-lived branches are a quiet tax on a team’s speed. The longer a branch lives away from master, the more painful the merge: someone else’s code has moved on, yours has gone stale, and “merge hell” eats the hours you wanted to spend on the product. Trunk-based development proposes the opposite: everyone commits to one trunk in small pieces, several times a day.
But an honest question follows: how do you ship unfinished functionality to master without showing it to users? The answer is feature toggles. Code goes to production “locked” — the flag is off and the user sees the old behaviour. When the feature is ready the flag flips, with no new deploy. Deploy (getting code onto the server) and release (opening a feature to people) stop being the same event.
That separation is the core idea. Deploy becomes technical, routine and safe; release becomes a product decision you can make at any moment and undo just as fast. A developer merges unfinished code behind a flag every day, and the business opens the feature when it is ready.
Toggles differ by lifetime, and mixing them is harmful. Release toggles hide unfinished features and are deleted right after full rollout. Experiment toggles serve A/B tests and live for weeks. Ops toggles (kill switches) let you disable a heavy feature under load. Permission toggles open capabilities to specific segments — a beta group, say.
On Unleash all of this becomes infrastructure rather than a scatter of if-statements: a central flag store, rollout strategies (by percentage, by segment, by attribute), a “who flipped what and when” audit, and instant rollback. Something broke in prod — flip the toggle in a second instead of pushing a hotfix for twenty minutes to a chorus of alerts.
The approach has a cost worth naming honestly: discipline. Trunk-based does not work without solid CI and automated tests — otherwise frequent commits to the trunk turn it into a minefield. And flags must be removed: a dead toggle left “just in case” for a year is technical debt and an extra branch of logic. A good practice is to file the removal ticket the moment you create the flag.
In real life it looks like this: create a flag, hide the new logic behind it, merge into master in small PRs, roll out to 1–5% of users, watch the metrics, expand to 100% — and delete the flag. If anything goes wrong at any step, rollback is one click.
The numbers I’ve seen in practice: time to ship new features drops by about 30% and production incidents by about 25%, because “rolling back” now means “flipping a switch” rather than assembling a release again. Trunk-based removes merge pain; feature toggles remove release fear. Together they are what people call continuous delivery.