Git Management Model of Configuration Management Tool

This article contacts your own project experience and online materials, plus some personal experiences. This article is specially written out of your passion for git tools.
Git Handling Model

Http://www.nuoyapingtai.net Noah platform www.nuoyapingtai.net
The common solution is to solve the node to the root and compare the path. See: http://www.lyhfyl.com
Distributed but centralized, this is the best discussion of the GIT handling model. Shows the model diagram:


The central origin is an "Intermediate Database". Of course, this intermediate database is considered to be like this (because git is distributed, there is no intermediate database at the skill level ).
Each developer's pull and push to origin, but in addition to the intermediate push-pull relationship, each developer can also get the pull changes from other developers. For example, for a large new feature, two or more developers may be organized before the code is submitted to the origin. There are several small teams: Alice and Bob, Alice and David, Clair and David. The team members first put the code pull to the team leader, and then the team leader pull to the origin database.
Primary Branch Design

The intermediate warehouse has two branches: Master and develop.
Git users should be familiar with the master branch on the origin, and there is a develop branch in parallel with the master.


Let's take origin/master as the primary branch. The head of the source code always indicates the production-ready (which can be arranged at any time) status. The Code on origin/develop is prepared for the next code release. Daily build is also based on this branch.
When the develop branch reaches a stable State and is ready to be released, all changes must be merged into the master branch and marked with the version number. In this way, a new layout will be released for each merger with the master. The commands are as follows:
$ Git checkout-B develop master
Develop jobs on the develop branch.
$ Git checkout master
$ Git merge-no-FF develop
Support Branch Design

Our development model uses some supporting branches placed beside the master and develop branches to facilitate parallel development between development teams. Unlike the primary branches, these branches have time constraints because they will be removed after all.
We will use different branches: feature branches, release branches, and Hotfix branches.
Each branch has its own role and has strict rules. For example, you can only create a new branch from which it can be merged.
Feature branches
The rules are as follows:
Inherit branch: Develop
Merge branch: Develop
Naming Standard: besides master, develop, release-, Hotfix-
Feature branches is used to develop new features (both short-term and long-term ). When new features are developed, it is likely that you do not know which policy version this feature will take. Once the development is complete, it can be merged to develop. Of course, if the development fails, it can be discarded.
Create and complete a feature Branch
According to the feature branches rule, the creation command is as follows:
$ Git checkout-B myfeature develop
New features can be merged to develop at the end
$ Git checkout develop
$ Git merge -- no-FF myfeature
$ Git branch-D myfeature
$ Git push origin develop
-The No-ff (Note: No fast foward) label creates a new commit record for each merger. Even if this commit is only fast-foward, it can prevent information loss.


Release Branch
The rules are as follows:
Inherit branch: Develop
Merge branch: Develop and master
Naming Standard: release -*
Release branch is prepared for the new production release. It can have small bugs and prepare metadata for the release (version number, build date, and so on ). Put all these jobs in release branch, and develop branch will be able to better understand what features should be developed in the next version.
The key factor from the merger of the develop branch to the release branch is that the develop branch meets the requirements of the release branch. At least all features of the release will be merged. The features that will be available in the future can be put first. Then, assign a version number for the version to be released.
Create a release Branch
Release branch is created after the develop branch. For example, suppose 1.1.5 is the current production release, and then there will be a relatively large version release. The status of develop is now available for release. After discussion, the resolution is published as version 1.2. Therefore, let's create a release branch and give it a new version number.
$ Git checkout-B release-1.2 Develop
This new branch may take some time until it can be merged into the production branch. During this period, bug fixes can be performed on this branch (instead of the develop branch ). Adding new features (especially large ones) is not allowed. After all, it is still to be merged into the develop, and then continue to be developed on the develop branch until the next version.
End a release Branch
When release branch is ready, you need to do a few things. First, the release branch is merged to the master Branch (each commit to the master is a new version, remember ). Add tags to commit on the master to facilitate future checks and rollback. After all, the changes made on release need to be merged into the develop Branch to ensure that the bug has been fixed.
The first two processes:
$ Git checkout master
$ Git merge -- no-FF release-1.2
$ Git tag-A 1.2
To save the changes on the release to develop, we need to merge the changes to develop.
$ Git checkout develop
$ Git merge -- no-FF release-1.2
This process may cause conflict. If this is the case, handle the conflict and submit it again.
Now that everything is finished, we can take the release branch out.
$ Git branch-D release-1.2
Hotfix Branch
The rules are as follows:
Slave branch: Master
Merge branch: Develop and master
Naming Standard: hotfix -*
Hotfix branch and release branch are somewhat similar. They are all prepared for the new production release. For example, if a bug is found in the running process, it is necessary to quickly process it. Then, a hotfix branch can be created and merged to the master branch after processing. The advantage is that developers can continue their jobs and have someone to handle this bug.
Create hotfix Branch
Hotfix is created from the master branch. Assuming that the runtime version was 1.2 and a bug was found, but develop was still under development and was not stable, a new hotfix Branch could be created and the problem could be solved.
$ Git checkout-B hotfix-1.2.1 master
Handle the problem, one or several times of COMMIT
$ Git commit-M "fixed severe production problem"
Hotfix branch finished
At the end, the bugfix will be merged to the master and the develop together to ensure that the bug has been fixed during the next release. This is the same as when release branch is finished.
First, update master and tag release.
$ Git checkout master
$ Git merge -- no-FF hotfix-1.2.1
$ Git tag-A 1.2.1
Merge with develop
$ Git checkout develop
$ Git merge -- no-FF hotfix-1.2.1
There is an exception, that is, when a release branch exists, the bugfix will be merged into the release instead of the develop, because the release will eventually be merged into the develop.
Remove branch after all
$ Git branch-D hotfix-1.2.1
Summary

 
This processing model should be regarded as a model that meets industry standards. In the practical development process, assuming that the project cost and the talent level of the project members are not too much considered, such a model should be the first choice.

Git Management Model of Configuration Management Tool