WGHD Git Code Warehouse branch management Instructions "Go"

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

　　Original Vincent Driessen

　　this article by Linux Big shed Bo Master summary streamlined.

　　1

GIT, on a technical level, is definitely a decentralized, distributed version control system, but at the management level, I recommend that you keep a central repository.

　　2

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

　　3

Make sure that the team members get the 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 code.

　　4

In a team development collaboration, I recommend that you have the concept of a "secondary branch."

　　5

The "secondary branch" broadly includes the following categories: The branch that manages feature development, the branch that helps build the published code, the branch that makes it easy to fix release critical bugs, and so on.

　　6

The most important feature of the "auxiliary branch" is that the "life cycle is very limited" and can be cleared upon completion of the mission.

　　7

I suggest that at least three classes of "auxiliary branches" should be set up, which 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" originates from the "develop" branch, which is implemented by:

git checkout-b myfeature Develop

　　11

"Feature branches" is ultimately attributed to the "develop" branch, which is implemented in the following way:

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", originating from the develop branch, is 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 preparations", "minor bug Fixes", "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 that the "develop" branch has basically reached the desired state, and at least you want the new feature to be fully merged from "Feature branches" to "develop" branch.

　　15

Create a "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 "Release branches", we can continue to fix bugs. 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" originates from "master", which is attributed to "develop" or "master", usually named "hotfix-*"

　　19

"Hotfix branches" is similar to "Release branch", but producing this branch is always an unexpected critical bug.

　　20

The reason for the proposed "Hotfix branches" is that the development of new features that want to avoid the "develop branch" must give way to bug fixes.

　　21st

Establish "Hotfix Branches" by:

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 is fixed, you need to merge "Hotfix branches" back into the "master" branch and also merge back to the "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

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

over~

WGHD Git Code Warehouse branch management Instructions "Go"