Trunk Based Development is the practice of small, often merges / commits into mainline in a Version Control System, with Trunk being the mainline branch (
This workflow is a counter-proposal to branch-focused workflows, like Gitflow, that allow multiple developers to work in parallel in their dedicated “feature branches” for long(er) time.
The assumption is that complexity in merge (the various dev branches) is a function of time and (branch) amount. This complexity will cause pain. Hence the goal of Trunk Based Development is to minimize time spend in merging / synchronization efforts.
The Trunk Based Development workflow supports Single Piece Flow and supplements processes that are tested and released automatically, which is striven for in DevOps. In short: It makes Continuous Integration possible.
- Scope of changes in commits to Trunk must be small, since it’s being deployed to production nothing but gradual changes are safe
- Probability of mistakes in due to complex merges will be reduces
- Habit of scoping tasks smaller, to have small resulting commits is fostered
- Culture of resilient engineering practices: When commits are being immediately deployed and have immediate negative impact then organizational knowledge of reliability patterns must establish - or organization / service is not sustainable.
- Verbose commit history, compared to feature-branch workflows, which in which merges (of large amount of commits) into Trunk often are cleaned, well described and squashed
- Automated Release optimized and hardened, as “being used to the limits all the time” as with no other workflow. It would annoy people the most if not fast & without hassle..
- Automated Testing is optimized and improved, as importance that it works reliable becomes extremely high, or service quality / reliability would be unacceptably low
- Trunk Based Development Website
- Atlassian: Trunk-based development
- Google / DevOps tech: Trunk-based development
- Wikipedia: Trunk (software)