VocalHyre
Sign up

CI/CD · Ship safely, repeatedly

What is trunk-based development and how does it work in practice?

Mediumtrunk-basedbranchingintegrationUpdated Oct 2026
Quiz this track

Short answer

Trunk-based development means integrating into a shared main branch at least daily through short-lived branches. Incomplete work is hidden behind feature flags, and automated tests keep the mainline releasable.

The mainline is the trunk. Developers either commit directly to it or use branches that live for hours to a day or two. The discipline is to make every integration small enough that conflicts and failures are cheap to resolve.

  • Keep branches short and merge before they drift
  • Use feature flags or branch-by-abstraction for work that is not ready to expose
  • Require fast reliable checks on every merge
  • Prefer small pull requests that one reviewer can understand
  • Fix or revert a broken trunk immediately rather than building on it
sh
git switch main
git pull --rebase
git switch -c feat/order-summary
git push -u origin feat/order-summary
gh pr create --fill
Trunk-based development is not the same as committing every half-finished change directly to production. It depends on flags, tests and a pipeline that can stop a bad change.

Follow-ups you should expect

Interviewers use these to check whether the first answer was understanding or memorisation.

  1. 1How do you hide unfinished work from users?
  2. 2What branch lifetime do you aim for?
  3. 3How does trunk-based development change code review?
  4. 4What do you do when a merge breaks the trunk?

Say it in the interview

Trunk-based development is about integrating small changes into main at least daily, with branches that live for hours rather than weeks. Unfinished features stay behind flags so the code can merge without exposing them. The mainline stays releasable because every merge runs automated checks. It reduces merge risk, but it requires discipline around small changes, flags and fixing a red trunk quickly.

Use this as a model, not a script. Saying it in your own words is what makes it survive follow-up pressure.

Related questions

MediumHow do feature flags change the deployment model?EasyWhat does continuous integration actually require?MediumHow do you choose a version control branching strategy?

Reading is step one

Now say it out loud.

Understanding an answer and delivering it under pressure are different skills. Rehearse this topic in a live CI/CD mock interview and get scored feedback on depth, clarity and confidence.

Start a free CI/CD interviewBrowse all questions