Trunk-Based Development
Fast recall
Quick revision
Core answer
Whether the candidate knows trunk-based development still uses (short-lived) branches and depends on feature flags and strong CI rather than being chaotic 'commit to main' free-for-all
Believing trunk-based development means no branches at all, or attempting it without feature flags and comprehensive automated tests
Explain that frequent integration shrinks merge conflicts and that feature flags decouple deploy from release, letting incomplete code ship hidden behind a toggle
Interview-ready guide
Interview answer
Trunk-based development is a workflow where everyone integrates small changes into one shared branch, the trunk, several times a day.
Branches do exist, but they're extremely short-lived — usually a few hours, two days at most. The idea is to integrate constantly so conflicts and bugs show up early, instead of working alone for weeks and then hitting a giant merge. Companies like Google use this because it lets them deploy hundreds of times a day.
Feature flags are one common tool when deployed code must remain unavailable to users. Say I'm building a new checkout flow. I'd merge the first piece to the trunk the same day, but wrap it in a feature flag so it's hidden in production.
The next day I add the payment step and merge again, still behind the flag. So the feature is sitting in production the whole time, just dark, and when it's done I flip the flag to release it. That separates deploying the code from releasing the feature.
The mistake freshers make is thinking trunk-based means no branches or that it's chaotic — you still use short-lived branches and pull requests. The other mistake is integrating changes without any safe incremental-delivery technique, which can expose incomplete behavior. And you absolutely need strong automated tests and fast CI, because if you're merging ten times a day, the tests are what keep production stable.
The payoff is far fewer merge conflicts and really fast feedback, but it takes discipline: small commits, high coverage, and a mature pipeline.
Trunk-Based Development
Direct Answer
Trunk-based development integrates small changes into one shared trunk frequently. Developers either commit directly under strong controls or use very short-lived branches. Feature flags can separate deployment from release, but they are optional; branch by abstraction and incremental delivery are other ways to keep unfinished changes safe.
Deep Dive & Architecture
Trunk-based development keeps one shared branch as the main integration line and limits how far work can diverge from it. Small changes are integrated frequently, either directly under suitable controls or through short-lived branches.
The method does not require every developer to push several times per day, nor does it require feature flags for every change. A team can use incremental slices, branch by abstraction, backward-compatible database changes, or a feature flag when deployment must happen before user release.
The supporting practices are fast feedback, reliable tests, small reviews, and a way to stop incomplete behavior from affecting users. The boundary is important: a long-lived integration branch called develop is no longer serving as the trunk, while an unreviewed free-for-all on main is not a mature trunk-based workflow.
Code Example
// New behavior merged to trunk but hidden behind a flag
@Service
public class CheckoutService {
private final FeatureFlags flags;
public Order processCheckout(Cart cart) {
if (flags.isNewCheckoutEnabled()) {
return newCheckoutFlow(cart); // merged, still dark
}
return legacyCheckoutFlow(cart); // current production path
}
}
# Git side: small commits, rebase on latest, push to trunk daily
git pull --rebase origin main
mvn test # fast local feedback
git commit -am "feat: add new checkout skeleton behind flag"
git push origin main
Common Mistakes & Pitfalls
- Thinking it means no branches: branches exist, they're just very short-lived and merged via PR.
- No safe release technique: use flags, backward-compatible slices, or another deliberate method when work cannot be released yet.
- Weak tests / slow CI: merging to trunk ten times a day needs high coverage and CI under ten minutes, or you'll break production constantly.
Check your understanding
Answer these without looking back at the article.
- What is a .gitignore file and what should go in it?
- What are conventional commits and why do teams use them?
- What is GitFlow and what are its main branches?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.