Trunk-Based Development vs. GitFlow for High-Frequency Releases
This tests your grasp of modern CI/CD trade-offs. A great answer explains how TBD's frequent merges to main, decoupled from release by feature flags, enable velocity. Then, contrast this with GitFlow's complexity.
What's really being asked
This question assesses your systems thinking about software delivery. It's not a Git quiz. The interviewer wants to see if you can connect a low-level practice (branching) to high-level business goals (speed, safety) and articulate the challenges of organizational change. It tests your understanding of how modern, high-performing teams like Google's (with 25,000+ developers on one trunk) actually ship code continuously.
The full answer
First, define Trunk-Based Development (TBD): A model where all developers integrate small, frequent changes directly into a single main branch, often multiple times per day. Short-lived feature branches are permitted but must be merged within a day or two.
Second, explain the critical role of feature flags: They are the enabling technology that makes TBD safe. Incomplete or risky features are merged into main but are wrapped in a flag, keeping them disabled in production. This decouples code deployment from feature release.
Third, connect this to high-frequency, low-risk releases: Because main is always in a releasable state, you can deploy at any time. Risk is minimized because each deployment contains only a few small changes, and any problematic feature can be instantly disabled via its flag without a full rollback.
Fourth, detail the transition challenges from GitFlow: The primary challenges are cultural and procedural, not just technical. This includes instilling the discipline for small, atomic commits; building a robust automated testing suite to maintain trust in main; and investing in a feature flagging system. It's a fundamental shift from isolated work to continuous, shared ownership.
The mistakes people make
Describing TBD as having "no branches." TBD allows for very short-lived branches; the key is avoiding long-lived, divergent branches like GitFlow's develop.
Forgetting feature flags. Without flags, TBD is extremely risky, as half-finished work would constantly break the main branch. A senior answer must highlight flags as the core safety mechanism.
Claiming GitFlow is simply "bad." GitFlow was designed for a different context: scheduled, versioned software releases. Its weakness is its incompatibility with continuous delivery, not that it's an inherently flawed model for its original purpose.
Focusing only on Git commands. The question is about the development model and its impact on the business, not just the git merge vs. git rebase debate.
What usually comes next
"How would you manage database schema migrations in a TBD model with feature flags?" "At what team size does TBD start to break down, if ever?" "Walk me through the lifecycle of a single feature, from ticket to production release, using TBD and flags."
A concrete example
A team of 10 developers moves from a 2-week GitFlow cycle to TBD. Previously, their develop branch would diverge for 10 days, accumulating 5-10 large features and resulting in a painful 2-day merge/stabilization period. With TBD, they now merge 20-30 small commits to main daily. A new, complex feature is built and merged piece-by-piece over 5 days, but the entire feature is wrapped in a new-feature-enabled flag. The team deploys to production 5+ times a day. The main branch is always stable, and the new feature is invisible to users until the flag is turned on for QA, then a percentage of users, and finally everyone.
Interview question
In Trunk-Based Development, what is the key practice that enables frequent, low-risk deployments to production while maintaining a continuously releasable main branch?
- a.Enforcing that all new features are developed on long-lived, isolated feature branches.
- b.Requiring all developers to commit directly to the main branch without using any feature branches.
- c.Relying solely on comprehensive end-to-end testing before any code is merged to main.
- d.Utilizing feature flags to deploy incomplete or risky code to production in a disabled state.Correct
Why? this is the answer
The card highlights feature flags as the 'enabling technology' that makes TBD safe by decoupling code deployment from feature release, allowing incomplete features to be merged and deployed but kept disabled. While robust testing is crucial, feature flags specifically address the ability to deploy unfinished or risky code safely and frequently.
Just read this? Test yourself on what you have been reading.
Read the original → flagsmith.com
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. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles