Shulou(Shulou.com)06/03 Report--

I've been using Git Flow to build my Git branch for several years. However, I encountered some problems with Git Flow, most of which came from long-standing branches. The solution to these problems is Trunk Based Development. This is a very simple technology and the basis for effective continuous delivery. In this article, I will tell you how I made the transition from Git Flow to Trunk Based Development development through HolidayCheck's IOS development team. You will learn the most important steps, as well as the benefits from Trunk Based Development, please read on.

The problem with Git Flow

Merge conflict

Merge conflicts are very common when using Git Flow. The reason is simple: if you have multiple parallel functional branches that exist for a long time, they are likely to be changed in the same part of the code base in two different branches. Merging conflicts is not only frustrating for developers who need to resolve it manually. It also increases the risk of breaking some functionality in the code, because it's easy to make mistakes when you have to decide which version of the code to use. Even if you do the right thing when you merge one branch into another, it may happen that the combination of these two features affects your code.

Construction

Functional separation

You cannot test the combination of two functions until you merge into one branch. When you develop functionality for days or even weeks in a separate branch, problems arise due to the interaction of the two functions. When you are slow to respond to these issues, you may have to change more parts of the code you write for new features. This means that you have wasted a lot of time creating code that you no longer need.

Many different functional branches may also confuse manual testers of your software. They always have to know in which temporary environment new features can be found. Different phase environments often mean different build tasks, different screens for monitoring tasks, and so on.

Unpredictable release

There is another problem with Git Flow, which is the result of the above two points: if the functional branches have not been merged, it is impossible to know how long it will take to release. You don't know it because you don't know which mergers will conflict, and you don't know how the new features will affect each other. Not being able to release at any time will make you lack confidence.

Solution

Trunk Based Development

Good news! There is a solution to all the above problems, which is Trunk Based Development. You have only one main branch, the trunk (Master or Mainline). There are no more development branches, and there are no long-standing branches. All submissions will be merged into the trunk as soon as possible, at least once a day. By merging into the backbone so quickly, merge conflicts become very rare. Using short-term branches is one of the four simple techniques to avoid merge conflicts. Even if you encounter a merge conflict, it may be easy to resolve, because it hasn't changed that much since the last merge into the backbone. Interference between different functions is immediately visible and can be tested while the function is in progress.

Trunk-based development will also encourage your team to think and work with small Step, resulting in small submissions that can be quickly merged into the trunk. In general, small Step can reduce the number of errors and help create modular designs.

The biggest question: how can you avoid a problematic trunk if you push code to an unstable trunk every day, even if a function hasn't been completed yet? Please read on to find the answer.

How to switch functions from Git Flow to Trunk Based Development

Function switching

When I introduce Trunk Based Development development to my team at HolidayCheck, there is a first step that is absolutely necessary in order to quickly commit code to the trunk! Before we start our branch structure, we must make sure that we use a short-lived branch that can be integrated into the development branch as soon as possible. The solution is quite simple, and we start to use function switching-some switches in the source code determine whether the function is active or not.

As long as the feature is not ready to be released, it will be disabled. This allows us to push it into the development branch without breaking anything. Developers and manual testers can enable each feature hidden from the average user in some settings. The development branch is ready to be released at any time because unfinished functionality will be turned off. They will be pushed to the customer, but will not be visible. Once a function is completed, it will be opened and available in the next version.

When we switch these functions in our code, we realize that they are not only useful when developing functions! Even if the functionality is complete, it is very good to keep the switch in the code. If it is possible to remotely control switching for all users, we can quickly deactivate this feature as long as we find that it has a negative impact on our conversion rate or other key numbers. In addition, if any errors occur or the traffic load on the server is too high, we can always turn off the feature immediately. This is particularly important because we have to wait for days until Apple reviews and releases a new version of our IOS app. Being able to disable features without a new version is a very powerful weapon.

Now, with all the functions switched, we can do another great thing: the Amax B test! Because each feature can be controlled remotely, we can enable one feature only for some user groups and disable other features. By doing so, we can see the real execution of a function. We can test the new feature on a small test group and then decide whether it should be enabled for everyone, or remove it if we see a negative impact. We use Optimizely to control and evaluate our Ahand B tests, but other tools are also available.

A branch agrees to all

Now we can quickly merge our functional branch into the development branch (because the unfinished functionality has been disabled), and we can release the development branch at any time. The question is: do we still need a developer and a main branch? The answer is: no. We can just hand everything over to Master instead of the Develop branch. Master is ready to go into production (don't forget to run all the tests every time something is pushed into Master). If we want to create a distribution, we can create it directly from the main branch, or create a distribution branch for this. The most recently released submission is marked Git tag. So the second step after introducing the feature switch is to delete the development branch! Here, we are already Trunk Based Development!

Summary

Trunk Based Development makes my team more flexible. We can release our main branch at any time, and we don't have any major merge conflicts. The main branch that is always ready to go into production is a prerequisite for continuous delivery. Function switching is a prerequisite for Adeband B testing. They help us understand what our customers really want and make us more confident because we know that a feature can be disabled at any time. The result is less risk and more innovation.

Translator: Wang Zhiyu

JFrog China R & D engineer, once worked as an R & D engineer in VIPSHOP, is good at Java, has participated in the R & D and operation and maintenance of many Internet platforms, and now focuses on the field of Devops landing, continuous integration and continuous delivery.

Original author: Robert original address: https://team-coder.com/from-git-flow-to-trunk-based-development/

Welcome to reprint, but please indicate the author and source. Thank you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.