What is Trunk-Based Development?
Learn what trunk-based development is, how it prevents merge hell, and why it is a prerequisite for continuous integration and deployment.
Expected Interview Answer
Trunk-based development is a source-control practice where all developers commit small, frequent changes directly to a single shared branch — the trunk or main — instead of working in long-lived feature branches that diverge for days or weeks before merging.
Developers work in very short-lived branches, often lasting less than a day, or commit straight to trunk, and every change is expected to keep the build green through automated tests running in CI on each commit. Because integration happens continuously rather than in one large merge at the end, the classic pain of merge hell — resolving huge conflicts after weeks of divergence — mostly disappears. Incomplete or risky work is hidden safely using feature flags rather than isolated on a branch, which is why trunk-based development and feature flags are usually adopted together. This practice is a prerequisite for true continuous integration and continuous deployment, since a pipeline can only deploy trunk safely if trunk is always in a releasable state, and it is one of the core technical practices measured by the DORA (DevOps Research and Assessment) metrics as a predictor of high software delivery performance.
- Eliminates large, painful merge conflicts from long-lived branches
- Keeps the main branch continuously in a releasable state
- Enables true continuous integration and continuous deployment
- Surfaces integration problems within hours instead of weeks
AI Mentor Explanation
Trunk-based development is like a team that reviews and incorporates one small tactical tweak into the main game plan after every single practice session, instead of a few players secretly rehearsing a completely separate strategy for weeks before revealing it. Because each small change is folded in immediately and tested in that day’s practice match, there is never a jarring clash between an old plan and a wildly different new one. If a tweak does not work, it is caught and fixed the very next day, not after a month of divergence. The whole squad is always working from the same up-to-date game plan.
Step-by-Step Explanation
Step 1
Pull the latest trunk
Developers start each small unit of work from the current state of the shared main branch.
Step 2
Make a small change
Work is scoped to a short-lived branch or direct commit, typically completed within hours.
Step 3
Run CI on every commit
Automated tests validate the change immediately, keeping trunk continuously green.
Step 4
Hide incomplete work with flags
Unfinished features are merged behind a feature flag rather than isolated on a long branch.
What Interviewer Expects
- Understanding that trunk-based development means short-lived branches or direct commits to main
- Awareness that it is a prerequisite for real CI/CD
- Knowledge of feature flags as the companion technique for hiding unfinished work
- Mention of DORA metrics linking this practice to delivery performance
Common Mistakes
- Confusing trunk-based development with just “using Git”
- Assuming it means no branching at all, rather than short-lived branches
- Forgetting the role of feature flags in making it practical
- Not connecting it to why long-lived feature branches cause merge hell
Best Answer (HR Friendly)
“Trunk-based development means everyone merges small changes into the main branch constantly, often multiple times a day, instead of working in isolation on a feature branch for weeks. We keep the main branch always in a shippable state by running automated tests on every commit and hiding unfinished work behind feature flags, which is what actually makes continuous deployment possible.”
Code Example
git checkout main
git pull origin main
git checkout -b short-lived/add-price-rounding
# make a small, focused change
git commit -am "Round displayed price to 2 decimals"
git push origin short-lived/add-price-rounding
# open PR, CI runs automatically, merge within hours
git checkout main && git merge short-lived/add-price-rounding
git branch -d short-lived/add-price-roundingFollow-up Questions
- Why is trunk-based development considered a prerequisite for continuous deployment?
- How do feature flags make trunk-based development practical for large features?
- What CI practices are required to keep trunk always releasable?
- How does trunk-based development compare to Git Flow with long-lived branches?
MCQ Practice
1. What best describes trunk-based development?
Trunk-based development is defined by small, frequent integrations into a single shared trunk, avoiding long-lived divergent branches.
2. What companion technique is commonly used to hide unfinished work under trunk-based development?
Feature flags let incomplete code merge into trunk safely while staying disabled until ready.
3. What problem does trunk-based development primarily reduce?
Continuous small integrations prevent the “merge hell” that comes from branches diverging for weeks.
Flash Cards
What is trunk-based development? — Committing small, frequent changes directly to a shared main branch instead of long-lived feature branches.
What technique commonly pairs with it? — Feature flags, to hide unfinished work merged into trunk.
What is it a prerequisite for? — True continuous integration and continuous deployment.
What problem does it avoid? — Large merge conflicts from branches diverging for weeks.