Home > Article > Development Tools > Introducing one of the GIT code branch management models
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.
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:
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, these two are the mainstays of the branches. master
This 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!
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 <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>
The last git show-branch -a --no- From the output of the name
command, you can see that the branch of
is created based on master
If 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
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
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
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?
The above is about this
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 thephp 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!