In the ever-evolving landscape of software development methodologies, staying open to change and exploring alternative approaches is essential for growth and innovation. Recently, I had the opportunity to work with highly effective teams that had adopted a development technique known as “Trunk-Based Development” (TBD). This experience turned out to be a transformative journey that broadened my perspective on software development practices. In this blog post, I aim to share my insights and observations about the power of Trunk-Based Development.

What is Trunk-Based Development?

At its core, Trunk-Based Development challenges the conventional wisdom of using branches for code development. Instead, developers are expected to commit their code changes directly to the main branch of the repository. This approach may seem unconventional at first, but it comes with a host of benefits that can significantly improve the development process.

The Benefits of Trunk-Based Development

1. Speed of Execution: TBD allows you to go from ideation to code iteration to production deployment rapidly. This accelerated pace is a game-changer in delivering value to users quickly.
2. Eliminating Dead Time: Without the need for waiting on code reviews associated with branching, developers can maintain a single, focused context, leading to increased productivity.
3. Reduced Merge Conflicts: TBD fosters a mentality of merging early and merging often, minimizing the complexity of merge conflicts that often arise in branch-based development.
4. Smaller and Reversible Changes: By committing directly to the main branch, developers are more likely to make smaller, manageable code changes that are easily reversible if needed.
5. Early Conflict Detection: Issues and conflicts surface faster in Trunk-Based Development, encouraging developers to resolve them promptly, preventing them from becoming more challenging and time-consuming later.

Complementary Techniques for Trunk-Based Development

To fully harness the potential of Trunk-Based Development, consider incorporating the following complementary techniques:

1. Pair Programming: Practicing TBD doesn’t mean mean no code reviews. Pair programming ensures that the code you push has been reviewed by a second pair of eyes. This collaborative approach often leads to simpler, more maintainable solutions.
2. Feature Flags: Feature flags are a natural fit for TBD, particularly when developers are working on incomplete features. They enable the ability to hide unfinished functionality from users until it’s ready for release, providing safety and reassurance.
3. Continuous Delivery and Continuous Deployment: It’s essential to not pile up small commits and release them in one go. Instead, embracing Continuous Delivery (CD) or Continuous Deployment (CD) guarantees that changes are integrated smoothly, reducing the risk of disruptions for your fellow developers.

Tips for Successful Trunk-Based Development

To make the most of Trunk-Based Development, keep these tips in mind:

Avoid Merge Commits

A merge commit happen when there are commits that get pushed to the remote main branch and you don’t have them at the time of making your own commits. To be able to push your commits, you have to incorporate the other commit. That usually results in a new commit in the form of Merge branch 'master' of github.com:org/repo. Check this blog post for ways to avoid it. In a nutshell, use git pull --rebase.

Keep track of contributors

This next tip applies when you are pair programming while using TBD: Usually, one developer will be “driving” with their keyboard. All git commits will show up as made by the driver. We need a way to know both developers in case there is a problem with the change and only one developer is available. To solve this, we used a commit naming convention by prefixing every commit message with the developers initials like the following: AH/JE My commit message
There is also another way to solve this: you can append the names and emails of the others to the commit message:

Git message goes here

Co-authored-by: User One <user.one@email>
Co-authored-by: User Two <user.two@email>

This feature is supported by both Github and Gitlab

Conclusion

In my journey with Trunk-Based Development, I underwent a significant mindset shift. It was eye-opening to challenge my previous beliefs, especially the notion that the main/master branch should only house clean and finished code. Two key conditions facilitated this transformation: a willingness to embrace change and practical exposure to this alternative method. Remember, the primary goal is not about the branching strategy but about delivering quality and value to users quickly and sustainably.