Trunk-Based Development is a source-control branching model where developers collaborate on code in a single branch called 'trunk' or 'main', resisting pressure to create long-lived development branches. This approach avoids merge conflicts, prevents build breaks, and enables continuous integration by having teams commit changes to the trunk multiple times daily.

Unlike GitFlow or other branching models with multiple long-running branches, Trunk-Based Development uses short-lived feature branches only for code review before merging to trunk. Teams may optionally create release branches just-in-time for deployment, or release directly from trunk using a 'fix forward' strategy for bug fixes. The approach scales from small teams doing direct commits to massive organizations.

Google demonstrates this model at scale with 35000 developers and QA automators working in a single monorepo trunk. Teams must run full pre-integrate builds on their dev workstations before committing, and larger teams need build servers to verify commits haven't broken the build. Development may occur in VMs or cloud containers rather than local machines. The model has been practiced since the 1990s and is promoted in best-selling books like 'Continuous Delivery' and 'DevOps Handbook'.

While GitHub-flow practitioners will find similarities, Gitflow users will see this as very different from traditional branching models. The approach requires mastering techniques like feature flags and branch by abstraction for longer changes.