GIT branch management policy (GO)

If you are serious about programming, you will definitely use the version control system.

Now the most popular version management system, not git.

Git has many advantages over similar software. One notable point is that the version of the Branch (branch) and merge is very convenient. With some traditional version management software, branching operations actually generate a physical copy of the existing code, and git only generates a pointer to the current version (also known as a "snapshot"), so it's fast and easy to use.

However, it is too convenient to have side effects. If you don't pay attention, it's likely to leave a side-by-side, open-source repository, with branches everywhere, completely invisible to the backbone.

Vincent Driessen put forward a branch management strategy, which I think is very worthy of reference. It can make the evolution of the repository concise, the backbone clear, each branch of their respective, orderly. In theory, these policies apply to all version management systems, and Git is just for example. If you're not familiar with Git, skip the Example section.

First, the main branch master

First, the code base should have one, and only one main branch. All the official versions available to the user are published on this main branch.

The name of the GIT Main branch, which is called Master by default. It is built automatically, and after the repository is initialized, the default is to develop in the main branch.

Second, the development branch develop

The main branch is used only to distribute major versions, and daily development should be done on another branch. The branch we use for development is called develop.

This branch can be used to generate the latest overnight version of the code (nightly). If you want to formally release, on the master branch, the develop branch is "merged" (merge).

GIT creates a develop branch command:

git checkout-b Develop Master

To publish the develop branch to the Master Branch command:

# Switch to Master branch
git checkout Master

# Merging the Develop branches
git merge--no-ff Develop

Here's a little explanation of what the--NO-FF parameter of the previous command means. By default, Git performs a fast-forward merge (Fast-farward merge) that points the master branch directly to the develop branch.

With the--NO-FF parameter, a normal merge is performed and a new node is generated on the master branch. In order to ensure a clear version evolution, we would like to adopt this approach. For more explanations on merging, refer to Benjamin Sandofsky's understanding the Git Workflow.

Third, temporary branch

The previous two main branches of the repository: master and develop. The former is for official release, the latter for daily development. In fact, the permanent branch only needs these two, it is enough, do not need the other.

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

* Function (feature) branch

* Pre-release (release) branch

* Patch Bug (fixbug) Branch

These three kinds of branches are temporary needs, after use, should be deleted, so that the code base of the permanent branch is always only master and develop.

Iv. Functional Branches

Next, look at these three kinds of "temporary branches".

The first is the functional branch, which is designed to develop a particular function that is separated from the develop branch. After the development is completed, it is to be merged into develop.

The name of the function branch can be named in the form of feature-*.

Create a feature branch:

git checkout-b feature-x Develop

When the development is complete, merge the feature branches into the develop branch:

git checkout Develop

git merge--no-ff Feature-x

To delete a feature branch:

Git branch-d feature-x

V. Pre-Release Branch

The second is the pre-release branch, which refers to before the release of the official version (that is, before merging to the Master branch), we may need to have a pre-release version to test.

The pre-release branch is separated from the develop branch and must be merged into the develop and master branches after the pre-release is finished. Its name can be used in the form of release-*.

Create a pre-release branch:

git checkout-b release-1.2 Develop

After confirming that there are no problems, merge to the Master branch:

git checkout Master

git merge--no-ff release-1.2

# Make a label for the new node of the merge build
Git tag-a 1.2

Then merge to the develop branch:

git checkout Develop

git merge--no-ff release-1.2

Finally, delete the pre-release branch:

Git branch-d release-1.2

Six, Patch Bug branch

The last one is to patch the bug branch. After the official release of the software, there will inevitably be bugs. You will need to create a branch to fix the bug.

The patch bug branch is separated from the master branch. After patching is complete, merge into master and develop branches. Its name can be used in the form of fixbug-*.

Create a patch Bug branch:

git checkout-b fixbug-0.1 Master

After patching is complete, merge to the Master branch:

git checkout Master

git merge--no-ff fixbug-0.1

Git tag-a 0.1.1

Then merge to the develop branch:

git checkout Develop

git merge--no-ff fixbug-0.1

Finally, remove the patch Bug branch:

Git branch-d fixbug-0.1

Finish

Transfer from http://www.ruanyifeng.com/blog/2012/07/git.html

GIT branch management policy (GO)