Git branch management strategy
If you're serious about programming, you're bound to use a " Version Control System".
The most popular "version management system" right now is Git .
Compared with similar software, Git has many advantages. One of the most notable points is that version branching (branch) and merging (merge) are very convenient. In some traditional version management software, branching actually generates a physical copy of the existing code, while Git only generates a pointer to the current version (aka "snapshot"), so it is very fast and easy to use.
However, being too convenient can also have side effects. If you're not paying attention, you're likely to be left with a sprawling, open repository with branches everywhere, with absolutely no clue of where the mainline is going.
Vincent Driessen proposed a branch management strategy that I think is worth learning from. It can keep the evolution of the repository concise, the trunk is clear, and each branch performs its own duties and is well organized. In theory, these strategies apply to all version management systems, Git is just an example. If you're not familiar with Git, just skip the examples section.
1. The main branch Master
First, the codebase should have one and only one master branch. All official versions available to users are released on this master branch.
The name of the Git master branch, which is called Master by default. It is created automatically. After the repository is initialized, the default is to develop in the main branch.
2. Development branch Develop
The master branch is only used to distribute major releases, and daily development should be done on another branch. We call the development branch Develop.
This branch can be used to generate the latest nightly version of the code. If you want to officially release it, you can "merge" the Develop branch on the Master branch.
Git command to create Develop branch:
git checkout -b develop master
Command to publish Develop branch to Master branch:
# Switch to the Master branch
git checkout master# Merge the Develop branch
git merge --no-ff develop
Here is a little explanation, what does the --no-ff parameter of the previous command mean. By default, Git performs a "fast-farward merge", which directly points the Master branch to the Develop branch.
After using the --no-ff parameter, a normal merge is performed, generating a new node on the Master branch. In order to keep the version evolution clear, we want to adopt this approach. For more explanation of merging, see Understanding the Git Workflow by Benjamin Sandofsky .
3. Temporary branch
The two main branches of the repository were mentioned earlier: Master and Develop. The former is used for official releases and the latter is used for day-to-day development. In fact, the permanent branch only needs these two, and no other is needed.
However, in addition to the permanent branches, there are also some temporary branches, which are used for version development for some specific purposes. There are three main types of temporary branches:
* feature branch
* Pre-release (release) branch
* Fix bug (fixbug) branch
These three branches are temporary needs and should be deleted after use, so that the permanent branches of the code base are always only Master and Develop.
Four, function branch
Next, look at these three "temporary branches" one by one.
The first is the feature branch, which is branched from the Develop branch in order to develop a specific function. After the development is completed, it must be merged into Develop.
The name of the feature branch, which can be named in the form of feature-*.
Create a feature branch:
git checkout -b feature-x develop
After development is complete, merge the feature branch into the develop branch:
git checkout develop
git merge --no-ff feature-x
删除feature分支：
git branch -d feature-x
五、预发布分支
第二种是预发布分支，它是指发布正式版本之前（即合并到Master分支之前），我们可能需要有一个预发布的版本进行测试。
预发布分支是从Develop分支上面分出来的，预发布结束以后，必须合并进Develop和Master分支。它的命名，可以采用release-*的形式。
创建一个预发布分支：
git checkout -b release-1.2 develop
确认没有问题后，合并到master分支：
git checkout master
git merge --no-ff release-1.2
# 对合并生成的新节点，做一个标签
git tag -a 1.2
再合并到develop分支：
git checkout develop
git merge --no-ff release-1.2
最后，删除预发布分支：
git branch -d release-1.2
六、修补bug分支
最后一种是修补bug分支。软件正式发布以后，难免会出现bug。这时就需要创建一个分支，进行bug修补。
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
创建一个修补bug分支：
git checkout -b fixbug-0.1 master
修补结束后，合并到master分支：
git checkout master
git merge --no-ff fixbug-0.1
git tag -a 0.1.1
再合并到develop分支：
git checkout develop
git merge --no-ff fixbug-0.1
最后，删除"修补bug分支"：
git branch -d fixbug-0.1
（完）