A team of twelve engineers integrates code many times a day and wants to keep merge conflicts and integration debt to a minimum by avoiding long-lived branches. They rely on a continuous integration build that runs on every commit to validate the shared line. Which branching strategy best matches this way of working?
- ATrunk-based development, where everyone commits small changes to a single shared branch frequently and short-lived branches are merged back within hours rather than days. Correct
- BA release branch model, where each version gets a dedicated long-lived branch that stabilises independently of the main line before any code is shipped to customers.
- CA forking workflow, where each engineer maintains a personal server-side fork and contributes changes back to the central repository only through pull requests across forks.
- DGitFlow, where parallel develop and feature branches accumulate work that is periodically promoted through release and hotfix branches before reaching the main branch.
Why A is correct: Trunk-based development keeps everyone integrating to one shared line with very short-lived branches, which directly minimises merge conflicts and integration debt for a team committing many times a day.
Why B is wrong: Release branches suit stabilising a specific version in parallel with ongoing work, but their long-lived nature is the opposite of the frequent small integrations the team wants, so it does not fit.
Why C is wrong: Forking workflows suit untrusted external contributors to open projects, but for a co-located trusted team they add cross-fork overhead and slow the frequent shared integration that is required here.
Why D is wrong: GitFlow is tempting because it is a well-known model, but its develop and feature branches encourage longer-lived divergence, increasing the integration debt the team is explicitly trying to avoid.