Topic
Feature flags vs branching
Branches and flags answer different questions. Branches isolate concurrent edits to the same files; flags isolate runtime behaviour for users and systems once code shares a lineage. Conflating the two is a common source of long merge queues and surprise behaviour in production.
Working on a shared mainline
Many teams aim to keep a single integration branch shippable most of the time. Incomplete work lands behind defaults that keep it invisible until ready — often a flag, configuration gate, or similar mechanism. The goal is smaller batches integrated frequently, not a mandate to delete all branches everywhere.
When feature branches still help
Code review, CI isolation, and experimental refactors can all justify a short-lived branch. The risk grows when the branch diverges for weeks: integration pain, silent conflicts, and a tendency to defer hard merges until the end. Flags do not remove the need to merge; they change what you can expose after merge.
What flags add after integration
Runtime steering
Once code exists in a release artifact, a flag can steer exposure without another deploy cycle — useful for canaries, internal dogfooding, or pausing a rollout while diagnostics run.
Not a substitute for design review
Hiding unfinished architecture behind a flag does not reduce coupling or data-model risk; it only hides the UI or entry point. Structural work still benefits from design conversation and incremental migration plans.
Coordinating teams
Flags can reduce the need for “big bang” integration weeks by letting multiple teams land code that is off by default. That only works if naming, ownership, and removal expectations are explicit — otherwise the mainline fills with dormant branches in boolean form.
Continue with implementation and best practices.