It is a source-control branching model where developers collaborate on code in a single branch called trunk, They therefore avoid merge hell, with having only one source of true, the trunk branch and with smaller commits. Do not break the build, since you have to check if the build it is still working on every commit.
This means that they're code will go to the trunk (main) branch and the repository will not have more than one main branch (e.g: a development branch or a release branch).
Who use it?
Giants from the tech like: Google, Atlassian, Facebook (meta), Microsoft, Amazon, etc...
CI/CD
Trunk-Based Development is a key enabler of Continuous Integration (CI)and by extension Continuous Delivery (CD). When individuals on a team are committing their changes to the trunk multiple times a day it becomes easy to satisfy the core requirement of Continuous Integration that all team members commit to trunk at least once every 24 hours.
How it works
Every developer will create smaller but continuous commits to the trunk through Pull Requests checking the build (it must pass before sending the code to the trunk). You can create a Continuous Integration (CI) with Github Actions to run the build, linter and tests on every new commit in the Pull Request to check it for you.
Continuous code review
After you finish your work and the Continuous Integration (CI) passed, someone should review your code, and after that merge your pull request with squash and merge, to create one commit with sub-commits were the sub-commits will be the smaller commits you have send to the pull request.
Indeed, in Trunk Based Development your commits will be small but continuous to guarantee the Continuous Integration (CI) but that also means that you will have continuous code review, since the commits will be smaller than usual it will enable a fast and simple code review of your code.
Continuous Delivery
With small commits, easy code review and the Continuous Integration (CI) checking the build, lint and tests you have a trunk (main)branch always ready for deploys and tests without having the necessity to create a new release branch to test the commits and deploys, your main branch can do it for you.
History
Trunk Based Development is not a new branching model. The word ‘trunk’ is referent to the concept of a growing tree, where the fattest and longest span is the trunk, not the branches that radiate from it and are of more limited length.
It has been a solution of the merge hell that the gitflow development causes with the multiple branches
Top comments (0)