PPL 2020 — Document Builder: GitFlow vs Trunk Based Development: A Developer’s Perspective
In my previous article about Git, I talked about the underlying implementation of git. In this post, I would like to talk more about two popular branching models of git, my experience on using them both in the industry and school projects, as well as my thoughts on the experience.
The two branching models I’m going to talk about are GitFlow and Trunk Based Development (TBD).
GitFlow
GitFlow is a branching model that is firstly introduced by Vincent Driessen. The main characteristic of GitFlow is the existence of long-lived branches. Typically in the codebase that implements GitFlow, there would be the main branch (master), the develop/staging branch, and feature branches.
The other main characteristic of GitFlow is the separation of concern. Developers can each work both collaboratively and independently in each of the feature branches, enabling the isolation of working on unfinished work from the finished ones.
The GitFlow that is implemented in our PPL project might be a little different from what is implemented in most of the industry because of the difference in some terms. However, they are essentially the same:
To summarize the flow in bullet points:
- Each developer branches off from staging (or in other similar models, called develop) and creates a feature branch called the PBI branch which stands for Product Backlog Item and develops a new feature on that branch
- Once a PBI is implemented, a merge request (or pull request) is made to the staging branch
- Once reviewed and accepted by other people in the development team, it is then merged to staging
- After the sprint review, if there is any PBI that gets rejected by the Product Owner, all code from that PBI branch is reverted in the coldfix branch
- All PBI that is accepted during the sprint review is then merged to master from staging
- If there is any live issue/production bug, the hotfix branch is used for bug fixing
The long-lived branches that I mentioned earlier in this flow are the staging, coldfix, and hotfix branches, as they are still being used even after the changes inside them are merged to master. PBI branches are relatively short-lived as they are no longer used when it has been merged to staging.
Trunk Based Development
Trunk Based Development (TBD) is a branching model that differs fundamentally from GitFlow. While GitFlow’s characteristic is to use multiple branches to encourage isolation of feature development, TBD is a model where developers work and collaborate in a single branch called trunk, or more well-known in the git world as master branch.
To summarize the flow of TBD in bullet points:
- Each developer creates a feature branch that always branches off from master (the trunk)
- Feature branch usually include very small changes (only contains 1–3 commits of code)
- The code is then pushed to a merge request/code review tool to be reviewed by other people in the development team. In this process, the code is usually also being tested through CI/CD to make sure that it doesn’t break anything once it is merged to master
- Once the code review is accepted, the code is then merged to master. A series of unit tests and integrations tests are usually run before the code really resides in master, followed by continuous deployment.
Personal Experiences
I have contributed to codebases that implement GitFlow and those who implement TBD. I worked with GitFlow during my internship with Microsoft and also during Document Builder’s development in PPL. My introduction to TBD was during my internship with Dekoruma, and the large-scale implementation of it in Facebook mesmerized me during my time interning with them.
Through my experience, let me tell you my personal favorite: Trunk Based Development.
I think the branching model is tightly related to the engineering culture of a company. Take Microsoft for example, their main customers come from the enterprise, which means most of them are paying customers. For instance, large-scaled companies pay a huge amount of money to use Azure services and their business processes depend on it. Due to that nature, in my opinion, they take a more careful approach to release new features. They have code freezes and testing periods when releasing new features to production. GitFlow is the suitable branching model for this compared to TBD.
Facebook, on the other hand, was very popular by their “Move Fast and Break Things” culture. Even though “Break things” is no longer in their core values, I think their engineering culture still revolves on the idea of “Ship fast, fix fast”. Ship things fast to the customers, get feedback, and respond fast when problems arise. This is also the culture of Dekoruma, one of the companies in which I also experience TBD.
In a more mature infrastructure of TBD, when a developer pushes a change that is not yet ready to be released, usually there is a management system where you can programmatically “hide” the feature. In a less mature system, these kinds of changes are usually “virtually” hidden from customers by putting it on an unknown endpoint.
I personally like the TBD more than GitFlow because it allows developers to have one source of truth. This prevents people from wasting time on resolving merge conflicts, and also encourage people to push changes as little as possible. Little code changes are easier to be reviewed and this also prevents huge, bad practice code to make its way to the codebase.
Conclusions
The two branching models suit and work differently in different engineering cultures. Summarizing based on the articles I read about both models:
GitFlow is suitable for:
- Open Source Project → Open source projects often have a lot of contributors from all over the world, having strict control over access and which code gets to be pushed to which branch is necessary, that’s why GitFlow will be a suitable model for this.
- Well-established product → When working with well-established product, usually the changes that need to be done are related to optimization and performance. These changes tend to be more precise, thorough, and not time-constrained. When you don’t necessarily need to iterate development quickly, GitFlow is a suitable model.
- When there are a lot of junior developers working on the codebase → GitFlow enables a more thorough review and testing period and is more forgiving to mistakes than TBD. This is a suitable model if a lot of the developers on the codebase need supervision.
Trunk Based Development is suitable for:
- Quick development iterations → When your company holds the importance of “move fast, make mistakes, fix fast” and have quick development iterations, TBD will be suitable.
- When the project/company is just starting up → When you’re just starting up, the priority is to have a working MVP, TBD is a suitable model for that as it reduces a lot of layers and complexity from the development flow.
Feedback on the writing and second opinion is very welcome. Please be reminded that what I wrote in the above article is my personal opinion and does not represent my position or former position in any of the companies I mentioned.
Thank you, I hope it was useful!
References:
