Trunk Based Development vs Gitflow from continuous delivery aspect
“Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.”
— Melvin E. Conway
As Melvin Edward Conway says, every reaction, culture and communication of the team is reflected on the product. Trunk Based Development and Gitflow are not just a method that is answer of “how to keep source code via Version Control System(VCS)” question. They are company/team culture and development approaches. In this article, we will examine these approaches from the continuous delivery aspect.
In software industry, continuous delivery has always had a very important place. It is also very important that it is not enough to produce the product while competing with your competitors, how you produce that product and how you intervene in case of any negative situation. At this point, your continuous delivery method should take you one step further.
Trunk based development and gitflow are very valuable continuous delivery methods.
It has been observed that Trunk based development is better in most research and application practices for continuous delivery life cycle. You can find detailed, data-based comments and observations in the Accelerate: The Science of Lean Software and DevOps book, which is one of these studies and which I read and recommend.Let’s take a closer look at trunk based development and gitflow approaches (and comparison of code reviews, branch models etc.). Why and when we should use them.
Trunk Based Development
The official definition of Trunk based development is like this;
“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.”
Trunk based development has some pre requirements. If you want to apply trunk based development, your team has to do pair programming and your team must have worked together for a long time. Beside this requirements you should have very well designed and working test life cycle and continous integration module.
Note: if you do not have these requirements, please do not follow this method (especially pair programming). Otherwise, you may encounter unwanted results and problems.
Trunk based development recommends small batches for stories or works. It means enable to divide the works into small pieces with small pieces your agile team will produce fast, easy to test and continuous to product deliver. Thus, customer requests are fulfilled in the shortest and safest way.
Trunk based development recommends a short-lived branch structure, because of this approach you can easily intervene in any negative situation. In this model branches don’t live no more than one day. Another benefit of this model is merge conflicts, with this model you don’t have to deal with merge conflicts.
Trunk based development has no code review during merges codes, instead has code review sessions. Branches quickly merge to master branch. As you remember we said that the most important prerequisite is pair programming. With pair programming developers share their knowledges with each others and making weekly code review sessions. With this method products deliver quickly.
When and why we should use Trunk Based Development:
With this method you can deliver products very quickly and easily. If you want to a well designed and agile continuous delivery mechanism you should use this method. Trunk based development will take you one step ahead of your competitors.If you provide the prerequisites, there is no barrier to use this method.
“A successful Git branching model”, git-flow approach was put forward by Vincent Driessen about in 2010. Gitflow recommends developing in branches that are copied from the main branch and called feature branches. With this method, teams can develop code in a coordinated manner.
In Gitflow developers woking on feature branches, these branches were copied from the main branch. Usually in git-flow, branches live long-time and this situation leads to merge conflicts.The probability that merge conflict will occur in this model is very high. This conflicts take many times for solution, this situation negatively affects continuous delivery.
Gitflow recommends code review during code merging. In this way, the examined code (feature branch) is safely combined with the master branch. From continuous delivery aspect; code review is a time consuming situation. For this reason developer may wait another developers comments for pull request.
When and why we should use Gitflow:
Usually gitflow using with opensource project. Also, if your team is newly established and the number of inexperienced developers in your team is high, gitflow is used.
In this article, I tried to explain the difference between trunk based development and gitflow from continuous delivery aspect and in which cases we will get more efficient results with these methods.