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

Today, let's introduce the Git branch model that will be used in our work.

Paste the picture first as a sign of respect

Gossip

In the school, whether they write their own curriculum design or do projects for teachers, there are 2 or 3 people who work together to develop Git, but they simply use the code collaboration features it provides. In school projects, such as curriculum design, the teacher checks the development and then there is no maintenance, and the project for teachers is also based on the characteristics of the project: no persistence, one-time development, so there is no Git branch model. In an enterprise, an application often has a long lifeline and is composed of many iterative projects. at this time, in order to solve the problem of code collaboration among dozens or even hundreds of people, a complete set of standard code development process is needed.

I still remember that when I was a senior, I went to an internship in an enterprise. At that time, there were only three developers in a small team, there was no specification for the use of git, there was only one main branch of master, and there was no management specification for the project. At that time, there was often code coverage, all kinds of code merging, and the online code did not know which node the code was. By the time I left, I didn't use this branch model. After graduation, I joined a bank, not to mention the branch model. Git didn't use it until I moved to an Internet company this year. Therefore, you may not really use this branch model for your work, but if you are in an Internet enterprise, you are likely to use it.

Some friends feel a little dizzy when they see this big picture and seriously say that this is a picture that everyone is using, especially Internet enterprises. If they are little friends who don't have a job yet, they may be a little strange, it's all right, let's take a look at these contents.

Branch introduction

Master: the code for this branch is released to production code

Develop: the code for this branch is pre-released to production

Release: the code for this branch is the code released to production by the new version

Feature: the code in this branch is the code developed by the new requirements

Hotfix: the code for this branch is to urgently fix the code for production bug

Scenario assumption

Here are some scenarios that you may often face at work

The team leader assigns new requirements and arranges to be launched next week (assuming 1227). Do you have a branch of next week's version? Some words are very simple, checkout next week branch (feature_app1.1.0_1227) to develop on the line, then you need to create a new branch, from the develop branch to create a new feature branch (feature_app1.1.0_1227), and then change the corresponding pom.xml version number to 1.1.0-SNAPSHOT, pay attention to naming, for example, here I use feature as a prefix, you can also set a rule.

After the development of the feature_app1.1.0_1227 requirements, the tests were handed over. Unfortunately, there were n bug in the tests, and the bug was still fixed on the feature_app1.1.0_1227.

Finally, the day before the release, the test MM said that the n-round test was over, no problem, pull up the online version, and do a regression test again. At this point, you need to merge the feature_app1.1.0_1227 branch into the develop branch, then create a new branch release_app1.1.0_1227 from the develop branch, and then change the corresponding version number to 1.1.0-RELEASE.

In the morning of the release day, the test MM was tested with the release_app1.1.0_1227 version and found another bug. Don't panic, as long as it is not a production of bug, it is easy to solve. At this point you want to fix bug in release_app1.1.0_1227, remember that you can't change it on feature_app1.1.0_1227, the feature_app1.1.0_1227 branch doesn't help much anymore, just look at the code submission record.

In the evening, Anshengquan began to publish the version, and suddenly found that there was an anomaly. After locating the problem, I found that there was a line of code that was wrong. After confirming with the team leader, I made changes on the release_app1.1.0_1227 branch, repackaged and distributed the version, and verified it for a period of time. No problem.

The release is finally complete, and don't forget to merge the release_app1.1.0_1227 version into the develop and master branches. It is also important to merge the develop branch code to a version later than 1227 (if there is already a version later than 1227). Note: this step to merge the code should be careful, if there is a big conflict between other people's code merge, you need to find that developer colleague to merge the code. Finally get a good night's sleep.

Bid farewell to the old demand, ushered in the new demand, the following requirements development will follow the above steps.

The next day, NullPointerException was suddenly reported on production, and the location found that it was caused by a line of code that was not empty. It was confirmed again and again that the original data was not empty, but now it really needs to support that some data is empty, and need to urgently fix the bug. After confirming with the team leader, we pulled a hotfix_app1.1.1_1228 branch code from the master branch, repaired the NullPointerException, went online after packaging, and verified that there was no problem. Merge the hotfix_app1.1.1_1228 branch into the develop and master branches, and merge the develop branch to a later version of 1227.

Well, a lot of text describes the development process based on the branch model. Different companies may have slightly different applications, but the overall process is the same. For example, some companies may merge release into master and release it to production with master code. If there is an exception in the release version, then pull the hotfix branch from the master branch to fix it. The steps described above are different. If an exception occurs when publishing the version, it can be fixed directly on release. Don't worry too much about these small differences.

I hope this article can make you realize that there is such a standard Git branch model, whether in work or study, in the need for branch management, recall that there is such a diagram, according to your scenario and then apply it, it will certainly take a lot of detours.

Official account original text: mature Git branch model

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.