Trunk Based Development is a source-control branching model where developers work on a single branch called 'trunk' (also known as 'main' or 'master' in Git), resist any pressure to create other long-lived development branches. They therefore avoid merge hell that happens with multiple parallel long-lived branches.
This model encourages developers to integrate their code into the trunk branch as often as possible, at least once a day. This encourages collaboration and reduces the risk of complex merge conflicts.
Here is a high-level overview of the Trunk Based Development model:
-
Trunk/Main/Master: This is the main line of development, and all changes to the project are committed here. It's always in a production-ready state.
-
Short-lived Feature Branches (optional): While Trunk Based Development encourages committing directly to the trunk, it's sometimes practical to use short-lived branches for developing individual features or fixes. These branches are usually created by individual developers for their own work, and they're merged back into the trunk as soon as the work is done.
-
Release Branches (optional): Some teams using Trunk Based Development choose to create a branch for each release of the software. Once a release branch is cut from the trunk, no new features are added to it, only bug fixes.
The key difference between Trunk Based Development and other models like GitFlow or Feature Branching is its emphasis on keeping all development work integrated on the trunk, rather than using long-lived branches. This is beneficial for continuous integration/continuous deployment (CI/CD) and DevOps practices as it encourages frequent code integration, making the process of releasing software faster and more reliable.
However, it requires good testing and integration practices, as all developers are working on the same branch and changes are integrated as soon as they're done. Any breaking changes can therefore affect all developers working on the project.
