Git Branching Best Practices – Trunk-Based Development

Trunk-based development is a prominent source code Branching Strategy that follows a set of defined principles and best practices to perform code development on a branch called ‘Trunk’ or ‘Master’ in a collaborative way.

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *, resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.

_ Source https://trunkbaseddevelopment.com/

We will cover the below aspects in the article,

Trunk-based development is getting huge traction recently.

These recognitions are mainly due to the realization of the fact after a decade of experience and learning on the various issue of traditional VCS (Version Control system) like Merge hell, Testing failure followed by a delay in delivering a feature and then delay in testing and acceptance, etc.

Origin and Merge Hell

The code integration phase is still an important phase even in modern code development methodologies. Generally, once a feature development is over as we know of integration of the code from different developers.

This merging sometimes also depends on multiple aspects like environment, the feature is integrated, the client-specific requirement being addressed, etc.

This merging is always challenging, as it involves a huge code base merge developed over a period of time.

The integration phase is always critical to delivery.

If any issue arising at that time could affect directly the delivery of the product.

The issue could become worse with an approach of having multiple parallel repositories in a different environment dealing with code movement from one environment to another environment.

Finally, These problems are always man-made. The good thing is these problems are solvable with best practices.

There are many mechanisms for practicing lean-agile methodologies.

Trunk-based development is slowly becoming one of the methods helping with a few common issues on code merge thereby targeting speed to the market initiative.

TBD actually complements your already established lean-agile practices and the team can get value from its usage.

Trunk Based development-based branching strategies help in practicing frequent releases and delivery of features and helping to achieve speed to the market initiative.

Trunk Based Development’s main advantage is that it keeps feature/code near to the production readiness right from the kickstart of a project.

It’s important to understand that when a feature or code is near to the release Or production readiness continuously, the team gets a lot of flexibility on revisiting the features, introducing a change in a feature or updating an implementation, or making changes to code as per the requirements.

Also, the team can revisit on design and architecture of applications if needed.

The team keeps on integrating code even if the feature is not complete. The idea here is simple, issues are easy to fix when they are small.

Trunk-based development encourages small features to be integrated in an incremental way.

A known limitation in the world of waterfall dealing with legacy source code, you will typically observe one continuous build that culminates in one deployment for a bunch of features spanning over a period of time.

Which most time produces multiple issues like merge hell and bugs etc.

Is it feasible to follow the Trunk/Master Approach?

The feasibility of following the trunk-based development could be a question for most of us.

The simple answer is ‘absolutely’ it is feasible.

There are multiple benefits of using the Trunk approach as explained in the “Benefits” section below.

Feature Toggle – Inevitable

There are multiple supportive techniques useful for following Trunk based development.

The use of Feature toggles is inevitable.

Feature toggles are dependable companions of trunk development and help to achieve the Trunk approach properly.

Trunk-based development can regulate the software development process within your sprint or iteration cycle.  

Teams develop a cadence for a release-ready feature implementation which is integrated together with feature flags.

Benefits of Trunk-Based Development

• Small incremental Feature development gives greater visibility of features being developed.

• Compliment the CI-CD process with Continuous Integration and continuous deployment of code.

• Small Feature development can be aligned with lean Agile methodologies improving the velocity of the team overall.

• Code on Master/Trunk is always ready to be released due to only one Trunk.

• Reduces the cost of manual code merge (usually done in the form of the integration process of the codebase).

• It enables the team’s ability to release new features more frequently.

• Trunk methodologies with a combination of practices improve the quality of deliverables.

• Shift-left enablement.

• Cross-team collaboration with XP practices.

• Eliminates heavy code merges.

Best Practices of Trunk-Based Development

Develop the Trunk/Master

• That means one and only Master or Trunk should be used for all development.
• This is different from Git Flow where actual development happens on dedicated branch-like DEV then Test etc.
• One should always use Feature Branches for small feature development.
• Small Feature Branch should not last for more than 1-2-3 days.

Feature Branch life span a few days(1-3 days)

• Developers should develop a practice of not keeping the code to themselves.
• The code should be merged with Master within a few days, typically 1-3 days.
• Code merge should be done for what you own that day with the precondition of a successful build, and test cases passing.
• Code merge can be done even if the feature is not complete. Make sure build and test cases are passing.

Create Feature branches from the Master/Trunk

Example

• Ex, If using Git as VCS then origin/master (remote) should be used for creating a Feature branch.
• The idea here is every new development should progress using the latest available code from Master/Trunk.

Feature Branches can be Aligned with the small feature and hence user stories or task

• New Feature branches can be created for small development and can be aligned with user stories or tasks.
• If aligned with a user story or task, please make sure the Feature branch code doesn’t last long beyond 2-3 days.
• The idea here is to merge and deploy small features in logical chunks and as early as possible usually within 1-3 days.

Clean merges to Trunk/Master

• The small feature developed should be validated, and reviewed within the Feature branch itself right before the merging to Master/Trunk.
• Always sync your changes from the source control.
• Feature branch code should be reviewed before the merge to the Master/Trunk.
• Clean merges here means code that is in a Green state i.e passes build, unit test, etc.
• Do only clean merges to Trunk which are validated and reviewed

Don’t commit to Master/Trunk directly

• It’s recommended not to commit directly to the Master/Trunk branch instead one should create a Feature branch (short 1-3 days).

• It’s recommended to create a feature branch for every merge.

• Smaller teams sometimes tend to check directly to the Master which is okay for a team of 1 or 2 (if code review is followed strictly.)

Merge should be from a Feature branch to the Master/Trunk

• Merge should be unidirectional that is from a Feature branch to Master/Trunk.

• Merge from the Release branch to the Master branch can be avoided.

• Intermediate merges to master (Trunk) are not allowed.

Every merge should be production-ready

• Do a clean merge with known and agreed functionalities including limitations if any.
• Do clean merges even if the feature is not completed fully.

Merges to Trunk/Master

• Merges between one Feature branch to another Feature branch must be avoided.

• The best practice is to follow the uni-directional merge that is merge of Feature Branch to Master/Trunk should be used.

Feature branch>>>> Master/Trunk>>>>>>Release Branch

Keep Trunk/Master Green

The definition of green can be defined as below,

• Green for the compile and build.

• Green for the Feature being developed. It should work with known and agreed functionality.

• Green for the acceptable Test including unit tests or integration test cases.

• If the build fails, revert your changes back to the previous best state of code. One should create a new Feature branch for fixing build issues.

Release branch to Master branch merge should be avoided

• Merge from the release Branch to the master should be avoided. There are rare exceptions though (which I will talk about in future articles).

References

• Cherry Pick in Gi for Trunk-based Development

Summary

Trunk-based development is a prominent source code Branching Strategy that follows a set of defined principles and best practices to perform code development on a single branch called ‘Trunk’ or ‘Master’ in a collaborative way thereby minimizing the merge/integration pain.

It complements continuous integration and continuous delivery by keeping the code “ready to release” state and developing a cadence of merging small changes in an incremental way.

---

Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.

---