What is trunk-based development, and how long do its branches live in Git?
answer
- One shared line, everything else temporary
- Measured in hours and days, not sprints
- Think about how far the merge base drifts
- Small batches make the short lifetime possible
- Trunk must stay releasable at all times
basics
~20 sTrunk-based development means everyone integrates into one shared branch — the trunk, usually main — continuously. Branches off it are short-lived, typically merged back within a day or two, so the repository never accumulates long-running parallel lines of development.
solid answer
~50 sIn trunk-based development there is exactly one long-lived branch, the trunk — `main` in most repositories — and every developer merges into it continuously, usually at least once a day. Work still happens on branches, but they are deliberately short: created from the current trunk tip, kept to a small batch of commits, and merged back before they can drift. The Git-level consequence is the shape of the history: a single dominant line with many short side branches joining it, rather than several branches living for weeks in parallel. That shape is the point — the longer a branch lives, the further its starting commit falls behind the trunk, and the more work integration becomes. The rule of thumb interviewers look for is that the branch's lifetime is measured in hours or days, not sprints, and that the trunk is expected to be releasable at all times.
code
bash · 9 linesgit switch main
git pull --ff-only
git switch -c fix-login-timeout
# a few small commits, same day
git switch main
git pull --ff-only
git merge --no-ff fix-login-timeout
git push origin main
git branch -d fix-login-timeoutgo deeper
Be ready to define it in one sentence — one shared branch, everyone integrates continuously, branches live hours to days — and to say that main is expected to stay releasable.
Explain why short lifetimes help mechanically: the merge base stays recent, so each merge reconciles little. Describe small batches as the practice that makes short branches achievable.
Demonstrate the operating reality — a broken trunk blocks the whole team, unfinished work must be mergeable while switched off, and the model depends on verification you actually trust.
Own the fit judgment: which release model and codebase structure the trunk assumes, and where supporting several shipped versions or outside contributors genuinely requires a different branching model.
## The model Trunk-based development is a branching model with one rule at its centre: there is a single shared line of development — the **trunk** — and everybody's work reaches it continuously. In Git terms the trunk is one long-lived branch, conventionally `main`. Everything else in the repository is temporary. That does not mean nobody uses branches. It means branches are **short-lived**: you branch from the current trunk tip, do a small piece of work, and merge back within roughly a day. Some teams go further and commit straight to the trunk. Both count as trunk-based; the defining property is integration frequency, not whether a branch object exists. ## What the history looks like The difference from a long-lived-branch model is visible in `git log --graph`. Trunk-based history is one dominant line with many short side branches joining it, each spanning a handful of commits. A long-lived-branch model produces several parallel lines that stay separate for weeks and then rejoin in large, difficult merges. Why that shape matters comes down to how Git merges. A merge is computed against the **merge base** — the common ancestor of the two branches. A branch created this morning has a merge base that is this morning's trunk, so the two sides differ by very little and the merge is usually trivial. A branch created six weeks ago has a merge base six weeks back, and Git must reconcile everything both sides did since. The difficulty of integration is a function of how long the branch has been diverged, and trunk-based development attacks exactly that variable. ## Small batches The practice that makes short branches possible is **small batches**: splitting work so each piece is independently mergeable. Instead of one branch that adds a whole feature, you land the data model, then the internal API, then the wiring, then the user-visible entry point — each merged to the trunk on its own. Every merge is small, every merge is reviewable, and the trunk is never more than a few hours behind anyone's work. This is also what makes the model's demands on the codebase real: if a change cannot be split, it cannot be landed in small batches, and the team ends up with a long-lived branch regardless of policy. ## Keeping the trunk releasable Because the trunk is the single line everyone builds on, it has to stay in a working state. Two disciplines follow. First, every merge is verified — the trunk is expected to be green, and a broken trunk blocks everybody, so it is treated as the highest-priority failure. Second, work that is not finished must be able to sit on the trunk without being active. That is what feature flags and branch by abstraction are for: they let incomplete code be merged and shipped while remaining switched off or unreachable, so "not finished" never becomes a reason to keep a branch alive. ## Where it fits and where it does not Trunk-based development pairs naturally with continuous delivery: if the trunk is always releasable and always integrated, a release is a decision rather than a project. It fits teams that deploy frequently from one line. It fits badly where the reasons for long-lived branches are structural rather than habitual — supporting several released versions in the field at once, or accepting contributions from people who cannot push to the repository at all. Those need a maintenance-branch or fork-based model. It also assumes strong automated verification: without it, continuous integration into one shared line means continuously sharing breakage. ## The interview answer A good answer names the single shared branch, the short branch lifetime, the daily integration cadence, and the reason: short branches mean recent merge bases and small merges. A very good one adds that the model's real cost is not in Git at all — it is the engineering work of making changes small and making unfinished work safe to have on the trunk.
- Does trunk-based development mean committing directly to main with no branches?No. Committing straight to the trunk is one variant, but most teams use branches — they just keep them short, typically under a day. The defining property is integration frequency, not the absence of branch refs. A branch that lives two hours and a direct commit produce nearly the same history and the same small merges.
- Why does a short branch lifetime make merging easier in Git terms?A merge is computed against the merge base, the common ancestor of the two sides. A branch cut this morning has a merge base from this morning, so both sides have changed very little since and there is almost nothing to reconcile. A six-week-old branch forces Git to reconcile six weeks of change on both sides.
Long-lived branches are like everyone drafting a chapter privately for two months and reconciling at the end; trunk-based development is everyone editing the shared document daily, so no two versions ever drift far apart.
saying these in an interview costs you the question
- Says trunk-based development forbids branches entirely
- Thinks it is just Git Flow without a develop branch
- Ignores that the trunk must stay releasable
- Claims it removes the need for review
- Believes it works without automated verification