Introducing one of the GIT code branch management models

gib tutorialThe column introduces the code branch management model

Recommended (free): gib tutorial

It’s like people are scattered and it’s hard to lead a team. There are many code versions and branches are hard to manage.

When the product development reaches a certain level, multiple versions will be available at the same time. Development, various hot fixes and other issues will inevitably bring about version branch management problems. Today we are going to take a look at the first code branch management solution.

I want to emphasize here that each branch management method has its own merits. No one is necessarily better than the other, only who is more suitable for you.

Popular Successful Code Branch Management

Our branch management solution is derived from this article called A Successful Git Branching Model. Many corporate projects are managed in this way. The following picture covers various branch designs in this way:

A successful Git Branching Model

This model can basically meet the needs of enterprises We will try to break down the various code version management requirements encountered during the project development process: , you can see that the names of two branches are bolded:

master

and

develop

, these two are the mainstays of the branches. masterThis is the first branch after creating a new GIT repository. In this model, the master branch represents the version on the current product line. Its last commit may be already online, or it may be a function that has been tortured by QA/PD/PO tens of millions of times and can be online in minutes. In other words, this branch must be available online at any time! If anyone submits a general-developed function to this version, he may be dragged to death by the PO! Therefore, if there is strict permission management, this branch will usually be locked, and only online colleagues have permission to move it!

In addition, every time the master goes online, a tag will be added to indicate the version number.

develop

Generally, primates are in awe of such operations as offering sacrifices to the sky, so we One needs to break new ground to make a big difference. In order to be consistent with the large army, the branch of

develop

is created based on

master

<div class="code" style="position:relative; padding:0px; margin:0px;"><pre class="brush:php;toolbar:false">C:\githome\github\gitdou (master) (gitdou@0.1.0) λ git branch * master C:\githome\github\gitdou (master) (gitdou@0.1.0) λ git checkout -b develop Switched to a new branch 'develop' C:\githome\github\gitdou (develop) (gitdou@0.1.0) λ git show-branch -a --no-name * [develop] add httpUtil.js  ! [master] add httpUtil.js   ! [origin/HEAD] add httpUtil.js    ! [origin/master] add httpUtil.js ----</pre><div class="contentsignin">Copy after login</div></div>The last git show-branch -a --no- From the output of the name command, you can see that the branch of

develop

is created based on masterIf the project is not particularly large, version management is relatively easy Simple, then the two branches master and develop are basically enough. There are various version management requirements, but you may not need every one. You can create these branches when needed, such as features

,

release, hotfix

---

features

The first situation is more common. There are many colleagues developing the project in parallel. For example, multiple modules are divided into multiple groups for development. If each module has If you throw it to the develop branch, then there is basically no way to do continuous integration (Continue Integration). Although the modules will definitely get along harmoniously during the final integration, during the development process, not every commit is necessarily compatible with the module, so it is best to make each module work in a corner by itself, and then it is best to be sure that it can be matched. If we fall in love, let's get together again. This is where we can create various feature branches based on modules. The relevant developers can develop on the corresponding branches. When each feature branch is basically completed, we will then add these branches Merge into develop

If there is a feature branch, then the develop branch will basically become an integration branch

release

As mentioned earlier, the master branch represents the version of the current product line, which can be deployed online in minutes without ending up like a sacrifice to the sky. However, some projects or teams have such a situation. Before the product goes online, it must be deployed to the quasi-product line for play. It will be tested internally for about a week. After making sure that there are no problems at all, it will be put on the product line. During the week of internal testing, if a problem is found, quickly fix it from the develop branch, and then go to the quasi-product line for verification. If we use the master branch to deploy a quasi-product line, and a problem is discovered during the week of internal testing, and at this time there are urgent problems on our product line that need to be fixed, then we cannot directly use the master branch Online, this cannot fulfill our previous promise: master can be online in minutes without having to sacrifice to the sky

So we can create a release branch to deploy and issue quasi-product lines Repair, until we confirm that there is no problem at all, we will synchronize to the master branch to go online

hotfix

How can there be no bugs in the system! When an innocent bug appears on the product line, which branch should we go to to fix it?

master: Obviously inappropriate. If there are bugs on the product line due to design or poor consideration, there is generally no need to sacrifice. However, if you make random changes on the master because of this, you may have to Sacrifice to heaven

• release: This is for the next version. If it is the previous version, then the new changes will destroy the meaning of the original version number. For example, the original branch was called release-1.0.1, so after adding this version, will it still be called by this name?
• developer: If there are other functions under development, this will be added as soon as they are launched!
• feature: This is a bit far-fetched
• It seems that the above four branches are not suitable, so let’s come up with a new one, called hotfix. The hotfix branch is from The master branch is created directly and is used to make some urgent code repairs on the product line, or to temporarily add small functions. Developers develop directly on this branch. After the function is completed, they go directly to the master branch and go online.

Remember that every time hotfix is ​​online, the function must be synchronized back to the developer, and then to the branches of each feature

The above is about this

---

The explanation of the successful code branch management model

can basically meet the code version management needs of most projects in most companies! We will introduce another code branch management model later, which refers to a management method of our company. See you next time!

If you want to learn more about programming, please pay attention to the

php training column!

The above is the detailed content of Introducing one of the GIT code branch management models. For more information, please follow other related articles on the PHP Chinese website!