Demystifying Trunk-Based Development
Trunk-based development enhances software efficiency by minimizing merge conflicts and ensuring continuous integration. Small, short-lived branches keep code close to the main branch, facilitating frequent updates and reducing rebase issues. Feature flags help safely manage feature rollouts.
What is Trunk-Based Development?
Trunk-based development or TBD is one of a few different branching strategies that your team, or even you can use to bring features in quickly to the main branch of your workflow. When we talk or think about branching strategies, the first one that comes to mind is the GitFlow. GitFlow definitely has its place in the creation of software.
In order for your team to run like a well oiled machine, having a branching strategy at the forefront of your development practices will be key to getting code quickly out the door. All branching strategies can achieve that, but TBD, will give you that extra leverage without merge hell. We all love merge hell don’t we lol?
By now I am sure we have all heard the term “merge hell” and one of the catalysts for that is what I call the “rebase race”. Hurrying up to rebase changes that are pulled in from main in order to get your changes merged in, and fingers crossed nothing breaks. We have ALL been there. It isn’t fun. Another benefit of TBD is avoiding merge hell with small commits to the main branch.
Breaking TBD Down
At the core of trunk-based development you have a main branch or trunk. The reason we call it a trunk is because it is very much like a tree. A tree has the main trunk where all branches and roots come from. In varying branching strategies you are creating off shoots or branches from that main trunk.
Nowadays, the trunk is called main, at least in the git world. I have worked in other VCS’s (version control systems) like SVN and ClearCase where the main branch was called trunk. I am showing my age here. With those systems, once someone had control of the trunk, it was locked. You as an engineer couldn’t push or pull any changes. Sometimes, it made for a horrible time when that developer forgot they locked it. No one on the team could get features merged.
In GitFlow, the branching strategy 9 times out of 10 has long lasting feature branches that go on until a feature or bug fix is complete, a PR is submitted, then after a successful rebase, the code is merged. This can create a few different problems, but the biggest one being…yep you guessed it, merge hell. As other developers work on their features and fixes, their code is getting rebased and oftentimes, if the team is committing code frequently there are changes that need to be fixed.
TBD differs in that you are creating small, short lived branches that once approved, get merged into the main branch. You keep the feature or bug fix as close to the main branch as possible so the risk of merge hell is almost non-existent. Adopting a practice like TBD is an integral part in creating a culture of CI (Continuous Integration).
How to get started with trunk-based development?
Getting started with TBD isn’t as painful as you might think. Yes, there are versions of TBD where you work directly in main and only in main. I would advise against doing that. Before you ever start a process when it comes to the SDLC, best practices, and architecture decisions, make sure that you discuss it with your team. Having your team’s input will benefit everyone in the long run.
For newer projects do an initial commit to the main branch once your structure is set up and you have added all your directories and files.
Once you verify using git status that all changes have been added to the working directory, proceed with your initial commit.
Verify that your changes are committed and ready to be pushed using git status once again. Git status is one of the most important commands you should be running when working with a project. It will give you a piece of mind in knowing where your directories and files are in the flow.
From here, you would branch out as you normally would. Depending on how your team best practices are, branch names might look different. I always liked using the “last name/task # + name of feature/bug” style. What that looks like is this:
Now, you are working in your feature branch. This branch isn’t going to be long lived. Once you are done with your feature, that can even be behind a feature flag, make sure to submit a PR and get it merged in!
You can use feature flags to hide any features you are working on but also keep moving that branch back into main to relieve the headaches of merge hell. Throughout the course of the development process, the branch should look like this visually.
As you can see from the image above, this is what your branches should look like when using TBD.
Trunk-based development best practices
There are a lot of best practices and pros when using trunk-based development as your branching strategy. Below I have listed out some of the important ones.
- Merge hell becomes almost non-existent.
- Pulling in code from main should be 1:1 with your branch, or very close to it
- Removing the rebase race from long lived branches being merged in with older code
- Short lived branches
- The main branch is always the source of truth
Wrapping Up
TBD is a very efficient way to keep code close to main. If you are looking for a way to keep your projects in order without the risk of over-the-top merge conflicts, tbd is surely the way to go. Pairing feature flags with trunk-based development removes the worry of cutting a release with unfinished code. If the code is hidden behind a flag, there is no impact to the release of the newest features that should go out. Next time you are spinning up a new project, give trunk-based development a try!