Master the terminology behind feature branching and its tradeoffs versus trunk-based development.
0 / 5 completed
1 / 5
At standup, a dev mentions their work is isolated on its own branch until it's ready to merge into main. What is this workflow called?
Feature branching isolates work for a specific feature on its own branch, merged into the main line only once complete and reviewed. This keeps in-progress work from destabilizing the shared main branch. It contrasts with trunk-based development, where changes integrate into main much more frequently.
2 / 5
During a design review, the team debates how long feature branches should live before merging. What risk grows the longer a branch lives?
The longer a feature branch lives without merging, the more it diverges from main, increasing the risk of painful merge conflicts and integration surprises. This is the core argument for keeping feature branches short-lived. Long-lived branches trade short-term isolation for larger, riskier merges later.
3 / 5
In a code review, a dev rebases their feature branch onto the latest main before requesting review. What is the purpose of this?
Rebasing onto the latest main pulls in upstream changes and resolves conflicts incrementally before the final merge, rather than facing a large conflict all at once during review or merge. This keeps the branch's diff focused and easier to review. It's a common hygiene practice for feature-branch workflows.
4 / 5
An incident report shows a long-lived feature branch's merge introduced a regression that was hard to bisect. What practice would reduce this risk?
Merging smaller, more frequent increments makes each change easier to review, test, and bisect if something breaks, compared to one giant merge accumulated over a long-lived branch. This is a core argument for favoring short-lived branches or trunk-based development. Smaller merges reduce both risk and blast radius per change.
5 / 5
During a PR review, a teammate asks how feature branching differs from trunk-based development. What is the key distinction?
Feature branching keeps work isolated until it's ready, while trunk-based development favors integrating small, incremental changes into the main line frequently, often behind feature flags. Each approach makes different tradeoffs between isolation and integration risk. Teams choose based on their release cadence, team size, and tooling maturity.