[Switch] git branch management policy

If you take programming seriously, you must use the version control system ).

The most popular version management system is not git.

Compared with similar software, git has many advantages. One notable point is that the branch and merge (merge) of the version are very convenient. In some traditional version management software, branch operations actually generate a physical copy of existing code, while git only generates a pointer to the current version (also known as "snapshot, therefore, it is fast and easy to use.

However, it is too convenient to cause side effects. If you do not pay attention to it, it is very likely that there will be a branch in the branches and a version library that is open everywhere, and the development of the trunk is completely invisible.

Vincent Driessen proposed a branch management strategy, which I think is worth learning from. It makes the evolution of the version library concise and clear, with each branch performing its own duties and well-organized. In theory, these policies apply to all version management systems. Git is just an example. If you are not familiar with git, skip the example section.

I. Master Branch

First, the code library should have one and only one master branch. All official versions provided to users are published on this main branch.

The name of the GIT main branch. The default name is master. It is automatically created. After the version library is initialized, It is developed in the main branch by default.

2. Development Branch develop

The main branch is only used to distribute major versions. Daily development should be completed on the other branch. We call the Development Branch develop.

This branch can be used to generate the latest overnight version of the Code (nightly ). If you want to officially release it to the outside world, you can "merge" (merge) the develop branch on the master branch ).

Command for git to create the develop Branch:

Git checkout-B develop master

Run the following command to publish the develop branch to the master Branch:

# Switch to the master Branch
Git checkout master

# Merge the develop branches
Git merge -- no-FF develop

Here, I will explain a little about the meaning of the -- no-FF parameter of the previous command. By default, git runs fast-farward merge to direct the master branch to the develop branch.

After the -- no-FF parameter is used, the merge operation is executed normally and a new node is generated on the master branch. We hope to adopt this approach to ensure a clear version evolution. For more information about merging, see understanding the Git workflow by Benjamin sandofsky.

3. Temporary Branch

The two main branches of the version library are master and develop. The former is used for formal release, and the latter is used for daily development. In fact, the permanent Branch only needs the two.

However, in addition to the permanent branch, there are temporary branches for version development for specific purposes. There are three types of temporary branches:

* Feature Branch

* Pre-release (release) Branch

* Fix the bug (fixbug) Branch

These three branches are temporary and should be deleted after use, so that the permanent branches of the code library are always master and develop.

Iv. Function branches

Next, let's look at these three "temporary branches" one by one ".

The first is the function branch, which is used to develop a specific function and is divided from the develop branch. After the development is complete, it must be incorporated into the develop.

The name of the function Branch, which can be in the form of feature.

Create a function Branch:

Git checkout-B feature-x develop

After the development is complete, merge the function branches to the develop Branch:

Git checkout develop

Git merge -- no-FF feature-x

Delete the feature Branch:

Git branch-D feature-x

5. Pre-release Branch

The second is the pre-release Branch, which refers to the release of the official version (that is, before it is merged to the master Branch). We may need a pre-release version for testing.

The prerelease branch is divided from the develop branch. After the prerelease is completed, it must be merged into the develop and master branches. It can be named in the form of release.

Create a prerelease Branch:

Git checkout-B release-1.2 Develop

After confirming there are no problems, merge them to the master Branch:

Git checkout master

Git merge -- no-FF release-1.2

# Create a label for the new node generated by merging
Git tag-A 1.2

Merge to the develop Branch:

Git checkout develop

Git merge -- no-FF release-1.2

Finally, delete the prerelease Branch:

Git branch-D release-1.2

6. Fix bug branches

The last one is to fix the bug branch. After the software is officially released, there will inevitably be bugs. In this case, you need to create a branch for bug fixing.

The bug fix branch is divided from the master branch. After the patch is completed, merge it into the master and develop branches. It can be named in the form of fixbug.

Create a bug fix Branch:

Git checkout-B fixbug-0.1 master

After the patch is completed, merge it to the master Branch:

Git checkout master

Git merge -- no-FF fixbug-0.1

Git tag-A 0.1.1

Merge to the develop Branch:

Git checkout develop

Git merge -- no-FF fixbug-0.1

Finally, delete the bug fix Branch ":

Git branch-D fixbug-0.1