Reproduced A successful Git branching Model/git branch management is an art

Reprinted from: http://www.cnblogs.com/baiyw/p/3303125.html

English Original: http://www.nvie.com/posts/a-successful-git-branching-model/

Original Vincent Driessen

This article is based on the summary of the Linux greenhouse bloggers.

1, GIT, technically, is absolutely a decentralized distributed version control system, but on the management level, I recommend you maintain a central repository.

2, I suggest, a central repository (we call it origin) includes at least two branches, namely "Master Branch (Master)" and "Development Branch (develop)".

3. Make sure that the team member obtains code from the main branch (master) that is in the published state, and that the Development Branch (develop) should always be able to get the latest development progress.

4, in a team development collaboration, I suggest that there should be "auxiliary branch" concept.

5, "Auxiliary branch", broadly includes the following categories: "Management function development" Branch, "Help to build the published code" branch, "easy to fix release key bug" branch, and so on.

6, "auxiliary branch" the biggest characteristic is "the life cycle is very limited", completes the mission can be cleared.

7, I suggest at least also set up three class "auxiliary branch", we call "Feature branches", "Release branches", "Hotfix branches".

At this point, we have formed the following most important organizational group, consisting of two boldface branches (master/develop) and three fine-grained branches (feature/release/hotfixes).

8, "Feature branches", originated from the develop branch, will eventually be attributed to the develop branch.

9, "Feature branches" is often used to develop an independent new function, and its final outcome must be only two, one is to merge into the "develop" branch, the other is abandoned. The most typical "fearture branches" must exist in the team developer, rather than in the central repository.

10, "Feature branches" originated from the "develop" branch, the implementation method is:

git checkout-b myfeature Develop

11, "Feature branches" finally also attributed to the "develop" branch, the realization Way is:

git checkout devleopgit merge--no-ff myfeature (--NO-FF, not fast forward, which requires git merge even in fast A new merge Commit is also generated under the forward condition (here,--NO-FF is required to branch merge, which is intended to keep the original "Feature branches" integrity of the entire commit chain) git branch-d Myfeaturegit Push origin Develop

12, "Release branch", originated from the develop branch, and ultimately attributed to the "develop" or "master" branch. This type of branch is suggested to be named "release-*"

13, "Relase branch" is usually responsible for "short-term pre-release preparation work", "minor bug repair Work", "version number and other meta-information preparation." At the same time, "develop" branch can undertake the next new function development work.

14, "Release branch" the best time to generate a new submission is the "develop" branch has basically reached the expected state, at least hope that the new features have been completely merged from "Feature branches" to "develop" branch.

15. Create "Release branches" by:

git checkout-b release-1.2 develop./bump-version.sh 1.2 (This script is used to uniformly modify all the code involved in the version information to 1.2, in addition, users need to write according to their own projects suitable bump-version.sh) git commit-a-M "bumped version number to 1.2"

16, in a short period of time, on the "Release branches", we can continue to fix the bug. In this phase, the incorporation of new features is prohibited, and new features should be incorporated into the "develop" branch.

17, after a number of bug fixes, "release branches" on the code has reached the published status, at this time, the need to complete three actions: the first is to merge "release branches" into the "master" branch, The second is to make sure that the new submission on the master tag (record milestone), and the third is to merge "Release branches" back into the "develop" branch.

git checkout mastergit merge--no-ff release-1.2git tag-a 1.2 (use-u/-s/-a parameter to create tag object, not soft tag) git checkout developgit merge --no-ff release-1.2git branch-d release-1.2

18, "Hotfix branches" from "master", attributed to "develop" or "master", usually named "hotfix-*"

19. "Hotfix branches" is similar to "Release branch", but the resulting branch is always an unexpected critical bug.

20, the proposed establishment "Hotfix branches" The reason is: wants to avoid "develop branch" the new function development must for the bug fix gives way the situation.

21, the establishment of "Hotfix branches", the method is:

git checkout-b hotfix-1.2.1 master./bump-version.sh 1.2.1git commit-a-M "bumpt version to 1.2.1" (then you can start fixing the problem) git comm It-m "Fixed severe production problem" (after the issue is repaired, a second commit)

22, after the bug repair, you need to merge "Hotfix branches" back to "master" branch, but also need to merge back to "develop" branch, by:

git checkout mastergit merge--no-ff hotfix-1.2.1git tag-a 1.2.1git Checkout developgit merge--no-ff hotfix-1.2.1git Bra Nch-d hotfix-1.2.1

23, still remember the article at the beginning of the big picture, I suggest you take this big picture from here to download, print out, affixed to your desk wall, the benefits are self-evident.

Reproduced A successful Git branching Model/git branch management is an art