How does trunk-based development with toggles enable frequent, low-risk releases?
Tests decoupling deployment from release via TBD. Strong answers cover daily small trunk merges with toggles hiding unfinished work, plus the cultural leap from GitFlow's isolated branches to continuous integration and toggle hygiene.
What's really being asked
Whether you understand that branching strategy is a delivery mechanism rather than just a version control preference. The interviewer wants to see if you grasp how trunk-based development plus feature flags decouples deployment from release, and whether you recognize the organizational friction involved in moving from GitFlow's staged isolation to continuous integration.
The full answer
First, the mechanics of trunk-based development: all developers work on a single shared trunk or main branch, integrating small changes frequently, often several times per day, a practice organisations like Google use with over 25000 engineers in a single monorepo. Short-lived branches are permitted but must merge back within one to two days at most. Second, the role of feature toggles: they let incomplete code be merged and deployed while remaining invisible to users, which keeps the trunk always releasable and removes the need for long-lived feature branches. Third, the contrast with GitFlow: GitFlow uses multiple long-lived branches including develop, feature, release, and hotfix to isolate work and stage versioned releases, which creates integration delay and merge risk. Fourth, transition challenges: cultural resistance as developers abandon the safety of isolated branches and learn to integrate continuously; technical requirements including robust automated testing and CI pipelines that validate every small merge to prevent trunk breakage; and operational discipline around toggle management to avoid accumulating stale flags or toggle debt that complicates the codebase.
The mistakes people make
Claiming trunk-based development is simply having everyone commit directly to main without any process. Ignoring feature flags entirely and suggesting trunk can stay releasable with half-built features exposed to users. Asserting GitFlow is universally inferior without acknowledging it was designed for scheduled versioned releases where release branches provide necessary control. Overlooking the automation prerequisite and suggesting a team can adopt trunk-based development without fast reliable tests and CI guardrails.
What usually comes next
How do you prevent toggle debt from accumulating over time? What is your strategy for testing both the on and off states of a feature flag? How would you handle a long-running experiment or AB test in a trunk-based model? At what team size or release cadence does GitFlow become more appropriate than trunk-based development?
A concrete example
A team shipping a new payment gateway currently uses GitFlow with two-week release branches. When switching to trunk-based development, they begin merging payment code behind a feature toggle into trunk daily. The toggle keeps the new gateway hidden in production while integration happens continuously. The transition challenge is not the code but the habit: developers previously validated features in isolation for a week, and now must write comprehensive automated tests before merging because there is no release branch buffer to catch integration issues. They also establish a policy to remove toggles within fourteen days of full rollout to prevent debt.
Interview question
When moving from GitFlow to trunk-based development, why is the organizational habit shift considered more difficult than the technical migration?
- a.Because feature toggles require replacing the existing CI pipeline with a custom flag management system
- b.Because developers must give up the safety of isolated branches and learn to validate changes through continuous integration and automated testsCorrect
- c.Because trunk-based development forbids any branching and forces all engineers to commit directly to main
- d.Because GitFlow's staged release branches cannot be replicated with automated deployment scripts
Why? this is the answer
The card emphasizes that the hardest part of the transition is cultural, as developers must abandon the safety of isolated branches and rely on continuous integration and automated tests. B is a common misconception: TBD still permits short-lived branches and is not simply direct commits to main without process.
Just read this? Test yourself on what you have been reading.
Read the original → flagsmith.com
- #trunk-based development
- #feature flags
- #gitflow
- #ci/cd
- #branching strategy
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles