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

This article shares with you the content of a sample analysis of the GIT code branch management model. The editor thought it was very practical, so I shared it with you as a reference. Let's follow the editor and have a look.

As long as this branch management solution is derived from this article called A Successful Git Branching Model. Many enterprises' projects are managed in this way. The following figure covers a variety of branch designs in this way:

A successful Git Branching Model

This model can basically meet the requirements of various code version management encountered in the process of enterprise project development. Let's try to break this model down to you:

Hold on to the green hill and don't relax

In the figure above, you can see that the names of two branches have been bold: master and develop, which are the mainstays of the branches.

Master

This is the first branch after a new GIT repository is created. In this model, the master branch represents the version of the current product line, and its last commit may have been online, or it may have been tortured by QA/PD/PO thousands of times and can be online every minute. In other words, this branch can be online at any time! If anyone submits a general function to this version, he may be pulled by PO to offer sacrifices to heaven! Therefore, if there is strict rights management, this branch will generally be locked up, and only colleagues who are online have the right to touch it!

In addition, every time master is launched, it will type a tag to indicate the version number.

Develop

Most primates are in awe of the practice of offering sacrifices to heaven, so we need to open up a new world to make a difference. In order to be consistent with the large army, the branch of develop is based on master.

C:\ githome\ github\ gitdou (master) (gitdou@0.1.0) λ git branch* masterC:\ githome\ github\ gitdou (master) (gitdou@0.1.0) λ git checkout-b developSwitched to a new branch 'develop'C:\ githome\ github\ gitdou (develop) λ git show-branch-a-- no-name* [develop] add httpUtil.js! [master] add httpUtil.js! [origin/HEAD] add httpUtil.js! [origin/master] add httpUtil.js

The output of the final git show-branch-a-- no-name command shows that the branches of develop are created based on master.

If the project is not very large and version management is relatively simple, then the master and develop branches are basically sufficient.

Two blossoms in style

When the project is slightly larger, you will encounter a variety of version management requirements, but not all of them. You can set up these branches when you need them, such as features, release, hotfix.

Features

The first situation is quite common, the project has many colleagues to develop in parallel, such as dividing multiple modules to multiple teams for development, if each module is thrown into the develop branch, then there is basically no way to do continuous integration (Continue Integration) operation. Although the final integration of the modules will certainly live in harmony, but in the development process, not every commit is compatible with the module, so it is best to make each module in a corner, and so it is best to make sure that we can love each other, and then stick together.

This is that we can create various feature branches based on modules, and the developers concerned can just develop on the corresponding branches. When each functional branch is basically completed, we can merge these branches to develop.

If there is a feature branch, then the develop branch is basically an integrated branch.

Release

As mentioned earlier, the master branch represents the current version of the product line, which can be deployed online minute by minute without leading to the end of offering sacrifices to heaven. But some projects or teams have such a situation, the product should be deployed to the quasi-product line before launch, internal testing for a week or so, make sure there is no problem and then go to the product line. In the week of internal testing, if you find a problem, quickly fix it from the develop branch, and then go up to the quasi-product line to verify it. If we use the master branch to deploy the quasi-product line and find a problem during the week of internal testing, and there is an urgent problem on our product line to fix, then we will not be able to launch the master branch directly, which will not do what we promised: master can be online every minute without sacrificing heaven.

So we can create a branch of release to deploy the quasi-product line and fix the problem. Until we confirm that there is no problem at all, we can synchronize to the master branch to launch.

Hotfix

How can there be no bug in the system? When bug appears innocently on the product line, which branch are we going to repair?

Master: obviously not suitable, the product line due to poor design or ill-considered bug is generally not sacrificed to heaven, but if because of this, a random change in the master, then it may be sacrificed to heaven release: this is for the next version. If it is the previous version, the new changes will destroy the meaning of the original version number, for example, the original branch is called release-1.0.1, so will it still be called this name after adding this version? Developer: if there are some other features under development, you will go up a little bit with this when you go online later! Feature: that's a little too far.

It seems that the above four branches are not suitable, so come a new one, which is called hotfix. The hotfix branch is created directly from the master branch to do some urgent code fixes on the product line, or temporary add-ons. Developers develop directly on this branch, and after the completion of the function, go directly to the master branch and then go online.

Remember to synchronize the function back to developer and then to the branches of each feature every time hotfix is launched.

Thank you for reading! This is the end of the sample analysis on the GIT code branch management model. I hope the above content can be helpful to you so that you can learn more knowledge. If you think the article is good, you can share it and let more people see it.

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.