What is trunk-based development and how does it relate to CI/CD?
Learn what trunk-based development is, how it enables true continuous integration with feature flags, and why it keeps your mainline always releasable.
Expected Interview Answer
Trunk-based development is a branching strategy where all developers commit small, frequent changes to a single shared branch (the trunk or main), avoiding long-lived feature branches. It is the branching model that makes true continuous integration possible because everyone integrates their work into one line constantly.
Instead of isolating work on branches for days or weeks and merging later, developers integrate at least daily, keeping the trunk always releasable. Incomplete features are hidden behind feature flags rather than kept on separate branches, so unfinished code can ship safely while staying dormant. Because every commit lands on the same branch, the CI pipeline runs on the true integrated state of the code, catching conflicts and regressions within minutes rather than at a painful end-of-sprint merge.
- Eliminates painful long-lived merge conflicts
- Enables genuine continuous integration
- Keeps the mainline always releasable
- Shortens feedback loops on every change
- Pairs naturally with feature flags for safe incomplete work
AI Mentor Explanation
Think of a team where every batter's runs are added to one shared scoreboard ball by ball, instead of each keeping a private notebook to reconcile at the innings break. Trunk-based development is that single scoreboard: everyone commits to one trunk continuously, so the true match state is always visible and no one is surprised by a hidden tally when the notebooks finally meet.
Step-by-Step Explanation
Step 1
Work off a single trunk
All developers pull from and push to one main branch rather than creating long-lived feature branches.
Step 2
Commit small and often
Break work into tiny increments and integrate to the trunk at least once a day to minimise divergence.
Step 3
Hide unfinished work behind flags
Wrap incomplete features in feature flags so they can merge to trunk while staying inactive in production.
Step 4
Let CI verify every commit
The pipeline builds and tests each integration to the trunk, keeping the mainline continuously green and releasable.
Step 5
Use short-lived branches if needed
If branches are used at all, keep them alive for hours not days, and merge back quickly to avoid drift.
What Interviewer Expects
- A clear definition contrasting trunk-based with long-lived feature branches
- Understanding of why it enables true continuous integration
- Knowledge of feature flags for hiding incomplete work
- Awareness that the trunk must stay always releasable
- The link between frequent small commits and faster feedback
Common Mistakes
- Confusing trunk-based development with committing untested code directly to production
- Thinking it means no branches at all rather than short-lived ones
- Forgetting feature flags are what make merging incomplete work safe
- Believing it removes the need for code review
- Assuming it only works for small teams
Best Answer (HR Friendly)
“Trunk-based development means everyone on the team works on and merges into one shared branch very frequently instead of keeping their changes separate for weeks. This keeps the code always ready to release and lets the automated pipeline catch problems early, which is why it fits so well with continuous integration.”
Code Example
name: CI
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci
- run: npm test
- run: npm run buildFollow-up Questions
- How do feature flags support trunk-based development?
- How does trunk-based development differ from Gitflow?
- What problems arise from long-lived feature branches?
- How do you keep the trunk always releasable?
- Does trunk-based development scale to large teams?
MCQ Practice
1. What is the defining characteristic of trunk-based development?
Trunk-based development centres on integrating small changes frequently into a single shared trunk rather than isolating work on long-lived branches.
2. How is incomplete work typically kept out of production under trunk-based development?
Feature flags let unfinished features merge to the trunk while remaining inactive in production until they are ready.
3. Why does trunk-based development enable true continuous integration?
Because all changes converge on one branch continuously, the pipeline validates the actual integrated codebase, catching conflicts within minutes.
Flash Cards
What is trunk-based development? — A strategy where all developers commit small changes frequently to one shared branch, avoiding long-lived feature branches.
How is unfinished work handled? — It is merged behind feature flags so it can ship dormant and be activated later.
Why does it suit CI/CD? — Constant integration into one branch lets CI test the true merged state and keeps the trunk releasable.
How long should any branch live? — Hours, not days — short-lived branches are merged back quickly to prevent drift.