CI/CD & DevOps Practices Practice Question 2: Trunk Based Short Branches
CI/CD & DevOps Practices · Test 1 · question 2 of 10
Each developer on a team works on a feature branch for two to three weeks and merges to main at the end of the sprint. The last two days of every sprint are lost to painful merge conflicts and integration bugs. The team wants to adopt trunk-based development, but it must keep mandatory pull-request code review before anything lands on main.
Which working practice meets both goals?
Show answer and explanation
Answer:
Trunk-based development requires everyone to integrate into trunk at least once every 24 hours. It still allows short-lived feature branches for code review and CI checks, as long as each branch belongs to one developer (two when pairing), lasts no more than a couple of days, and comes back to trunk as a pull request. Work that is not finished is merged anyway and kept switched off with a feature flag. Option D keeps mandatory review and removes the long-lived branches that cause the merge pain.
Option A only renames the problem. Weeks of work still collect on a branch that is not trunk, so integration with main is still delayed until the end of the sprint.
Option B keeps each branch up to date with main, but nobody's work reaches main until the sprint ends. Developers still never see each other's changes, so the conflicts between branches surface late, just as they do now. These are still long-lived feature branches, which trunk-based development treats as its antithesis.
Option C integrates the team's work more often, but on a second long-running branch instead of trunk. main still gets a large merge once per sprint. That is a branching model trunk-based development is meant to replace, not trunk-based development.
References: Trunk Based Development; Short-Lived Feature Branches