Embracing Trunk-Based Development at Hijra Engineering

http://thrivethinking.com/wp-content/uploads/2019/10/BehaviorChange1.jpg

At Hijra, we are continuously striving to improve our development processes to enhance collaboration, efficiency, and the quality of our software. Recently, we decided to transition from GitFlow to Trunk-Based Development (TBD).

GitFlow vs. Trunk-Based Development: Pros and Cons

GitFlow

https://nvie.com/img/git-model@2x.png

GitFlow is a branching model that utilizes multiple long-lived branches, such as ‘develop’, ‘master’, and ‘release’, along with short-lived feature, hotfix, and release branches. This approach allows for a structured, organized development process.

Pros:

• Clear separation of stable and unstable code: GitFlow keeps the ‘master’ branch stable, allowing for easier deployment and release management.
• Better support for parallel development: By isolating features in their branches, developers can work on multiple features simultaneously without interference.
• Easy tracking of hotfixes and release branches: GitFlow enables quick identification and resolution of issues in production.

Cons:

• Complex branching structure: The multiple branches can lead to confusion, especially for new team members.
• Frequent merges and potential conflicts: As features are developed in isolation, the integration process may require time-consuming merges and conflict resolution.
• Scattered PR history: Due to the various branches, PR history is often spread out, making it difficult to have a comprehensive view of the development process.

Trunk-Based Development

https://statusneo.com/wp-content/uploads/2022/08/tbd_workflow.drawio-1-1.png

In contrast, Trunk-Based Development (TBD) is a single-branch approach where all developers work directly on the main branch (‘trunk’). This model emphasizes continuous integration, frequent commits, and shorter-lived branches.

Pros:

• Simplified branching structure: With a single branch, TBD is more accessible for team members, reducing complexity.
• Easier PR history tracking: Since there is only one main branch, PR history is consolidated, making it simpler to review and analyze.
• Faster integration and fewer merge conflicts: By integrating changes frequently and directly into the main branch, merge conflicts are reduced, and issues are identified early.

Cons:

• Potential instability in the main branch: As all development occurs on the main branch, there’s an increased risk of introducing unstable code.
• Reduced support for parallel development: Developers need to be more cautious when working simultaneously, as their work is directly integrated into the main branch.
• Requires a strong emphasis on testing and automation: To maintain stability, the team must invest in robust testing and automation processes.

Hijra Engineering’s Transition to Trunk-Based Development

At Hijra, we recognized that our PR history was scattered across multiple branches, making it difficult to comprehensively understand our development process. We decided to adopt Trunk-Based Development to consolidate our PR history and streamline our workflow.

While we acknowledge the potential risks of TBD, such as increased instability in the main branch, we believe that our investment in robust testing and automation processes will mitigate these risks. Additionally, we have found that the simplified branching structure of TBD has improved collaboration and efficiency within our team.

The Hijra Engineering team’s transition to Trunk-Based Development is a testament to our commitment to continuous improvement. As we continue to adapt and refine our development processes, we look forward to sharing our experiences and insights with the broader software engineering community.

A Note of Reflection from Vincent Driessen

The GitFlow model was conceived in 2010, now more than a decade ago, and not very long after Git itself came into being. In those 10 years, git-flow (the branching model) has become hugely popular in many software engineering teams to the point where people have started treating it like a standard of sorts — but unfortunately also as a dogma or panacea.

Driessen reminds us that there is no one-size-fits-all solution. It is essential to consider the context of your team and project, avoid treating any model as a panacea, and decide the best approach for your specific needs. (The full *article* from GitFlow creator).

Originally published at https://www.linkedin.com.