A successful git Branch Model

 

English link:Http://www.nvie.com/posts/a-successful-git-branching-model/

Http://roclinux.cn /? P = 2129 # More-2129

Git is a decentralized distributed version control system. To facilitate management, it is best to maintain a central version library.

A central version Library (called its origin) should include at least two branches, namely "master" and "Development Branch )". Make sure that all the code obtained by the Team members from the master Branch is in the publishable status, and the Development Branch should always be able to get the code with the latest development progress.

For management convenience, at least three types of "Auxiliary branches" should be set, such as "feature branches", "Release branches", and "hotfix branches ".

At this point, the following most important organizational group is formed, including two master/develop branches and three sub-body word branches (feature/release/hotfixes ). The biggest feature of "auxiliary branch" is "limited lifecycle", which can be cleared after the mission is completed.

"Feature branches" originated from the develop branch and will eventually be attributed to the develop branch. "Feature branches" is often used to develop an independent new function, and there must be only two final results. One is to merge it into the "develop" branch, and the other is to be discarded. The most typical "fearture branches" must exist in team developers rather than the "central version library.

The lifecycle of feature branches includes the following operations:

Git checkout-B myfeature develop // development operation git checkout devleopgit merge -- no-FF myfeature (-- no-ff, that is, not fast forward, its role is: git merge is required to generate a new merge commit even under the fast forward condition (here, branch merge is required using the -- no-FF method, whose purpose is, to ensure the integrity of the entire commit chain of the original "feature branches") git branch-D myfeaturegit push origin develop

"Release branch" originated from the develop branch and is ultimately attributed to the "develop" or "master" branch. We recommend that you name this type of branch "release -*". "Relase branch" is generally responsible for "preparations before short-term release", "minor bug fixing", and "Preparation of metadata such as version numbers ". At the same time, the "develop" branch can undertake the development of the next new function. The best time for "Release branch" to generate a new commit is that the "develop" branch has basically reached the expected state. At least you want the new features to be fully merged from "feature branches" to "develop" branch.
In a short period of time, on "Release branches", we can continue to fix bugs. In this phase, the integration of new functions is strictly prohibited. New functions should be merged into the "develop" branch. After several bugs are fixed, the Code on "Release branches" has reached the publishable State. At this time, three actions need to be completed: the first is to merge "Release branches" into the "master" branch, and the second is to tag the new commit on the master, the third is to merge "Release branches" back to the "develop" branch.
"Release branches" has the following operations in its lifecycle:

Git checkout-B release-1.2 Develop. /bump-version.sh 1.2 (this script is used to uniformly modify all versioning information in the code to 1.2) git commit-a-m "Bumped version number to 1.2" Git checkout mastergit merge -- no-FF release-1.2git tag-A 1.2git checkout developgit merge -- no-FF release-1.2git branch-D release-1.2
"Hotfix branches" originated from "master" and is attributed to "develop" or "master". It is usually named "hotfix-*", and "hotfix branches" is similar to "Release branch ", however, generating this branch is always an unexpected critical bug. We recommend that you set up "hotfix branches" because you want to avoid the issue where the development of new features of the "develop branch" must make way for bug fixes.

"Hotfix branches" has the following operations in its life cycle:

Git checkout-B hotfix-1.2.1 master. /bump-version.sh 1.2.1git commit-a-m "bumpt version to 1.2.1" (you can then start fixing the problem) git commit-M "fixed severe production problem" (after the problem is fixed, for the second submission) (after fixing the bug, you need to merge "hotfix branches" back to the "master" branch, and also need to merge back to the "develop" Branch) git checkout mastergit merge -- no-FF hotfix-1.2.1git tag-A 1.2.1git checkout developgit merge -- no-FF hotfix-1.2.1git branch-D hotfix-1.2.1