Summary
Feature branching is the default Git workflow of many teams, and I consider it an anti-pattern. I wrote this article to say why, to explain what feature toggles offer instead, and to show with a small HR application in .NET how little it takes to start.
The harm is well known to anyone who has lived it: branches that diverge from main for weeks, merge conflicts that eat afternoons, bugs and vulnerabilities discovered at the merge instead of at the commit, and a queue of branches waiting for a release date. Each of these breaks one of the principles that make continuous delivery work: integrate continuously, test early, keep main always releasable. A short-lived branch merged within the day is fine; the anti-pattern is the branch that lives long, sometimes even deployed to production without ever coming back.
A feature toggle is a runtime switch. The code goes into main as it is written, unfinished or risky work stays hidden behind the switch, and the team gains what a branch never gives: canary rollouts, permission-based exposure, experiments, and a rollback that is a configuration change rather than a redeploy. The article names four kinds of toggle, release, ops, permission and experiment, and builds one with Microsoft.FeatureManagement: a feature filter reading a request header, a feature declared in configuration, a service that asks the feature manager which path to take.
Toggles ask for discipline in return: keep them temporary, name them consistently, test both paths, document them. With that, trunk-based development delivers short feedback loops, one fix per defect, less pain for reviewers and safer rollouts. Stop branching for features; start toggling them.
Key ideas
- Long-lived feature branches break continuous integration, shift-left testing and the always-releasable main branch; short-lived branches merged quickly are not the problem.
- A feature toggle is a runtime switch: unfinished work ships to main hidden, and rollback becomes a configuration change.
- Four kinds of toggle, release, ops, permission and experiment, each answering a different question about who sees what, and when.
- In .NET, a feature filter, a configuration entry and a feature manager are enough to put a new path behind a request header.
- Toggles need discipline: keep them temporary, name them consistently, test both paths, document every flag.
Why I wrote this
To explain why feature toggles are the more robust alternative for teams committed to continuous delivery, to break down what feature branching is and why it is a bad practice, and to show with a sample HR project in .NET how easy it is to get started.