Branch based vs Trunk based development

This post was originally posted in the newsletter GitBetter. If you are interested in leveling up your game in Git, you can subscribe to it.

Choosing the right-branching model can save you a lot of time in development. It also helps your dev team to work efficiently.

Coming to the point, we are gonna discuss two branching models today

1. Branch based

2. Trunk based

Branch based development

This is a very common strategy and most of them know it.

You have a stable branch like a master.

Then you have a feature branch like develop.

So whenever you develop new features or fix any bugs, you take a branch from develop and finish your work.

Then you raise a PR to the feature branch. After the code review, the branch will be merged.

When you have finalized the changes, then you merge the feature branch to master for the main release.

I know how common it is. Most of the open-source software use this method.

Trunk based development

On the other side, trunk based development doesn’t use branches or has very limited use of branches.

You have the main branch like master

Every developer will do all the changes in the main branch and push it directly to the main branch.

There are no PRs, branches, merge conflicts.

Just push directly to the main branch.

Seems very dangerous right?

With trunk-based development, you mostly can’t control who pushes the code and which code is being merged to the stable branch.

But there are things we have to consider with Trunk based development.

Trunk based development is useful when you want to deliver software in a fast phase.

And this method is always accompanied by best practices in writing software like TDD, CI/CD integration, Automation testing, high code coverage, pair programming, etc.

Trunk based development is a required practice of Continuous Integration (CI). With CI you get a deployment pipeline where you can run all tests and other integration jobs and safely deploy the code to production.

Most companies who are practicing CI often welcome Trunk based strategy.

Trunk based development is often practiced in a group of professional engineers. Because they have experience in writing software and know the best practices often. This comes with a high advantage.

Imagine a small group of professional engineers (maybe 10) who know best practices in development like TDD, Automation testing, etc, and are following Trunk based development. This group can deliver software in a fast and efficient way to its full potential.

This type of development is highly encouraged in Agile methodologies where you have to ship software frequently to get feedback often.

One can always argue that with Trunk based development you have very limited control over the code being released. It’s true but with the best practices, it can always be mitigated.

So choose your branching strategy wisely. If you need to deliver software in a fast phase, then Trunk based development is the best choice. On the other hand, if you need to tightly control the release you can follow a branch-based approach.

Thank you for reading :)

This post was originally posted in the newsletter GitBetter. If you are interested in leveling up your game in Git, you can subscribe to it.

Comments

[Adrian Matei]

I think trunk based development only makes sense you do pair-programming and don't need a code review, otherwise simply branch from master (no dev branch needed) and rebase master + squash/fixup (also git rebase) your branch after the review is ready and merge it.

See also - guides.github.com/introduction/flow/

[Doaa Mahely]

Hello Srebalaji. In the branch workflow, what would be the difference if we create new branches off master instead of develop?

[vaclavhodek]

Trunk-based branching is something very old from times when Subversion was still a thing and Git was unknown... It's more common for an environment with strongly coordinated development.