www.nvie.com/posts/a-suc…

By Vincent Driessen

This article has been condensed and summarized by the Linux greenhouse blogger.

1

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

2

I recommend that a central repository (we’ll call it Origin) have at least two branches, “Master” and “Develop.”

3

Make sure that team members get releasable code from the master branch, and that they always get the latest development code from Develop.

4

In a team development collaboration, I suggest the concept of a “helper branch.”

5

“Helper branches” generally include branches that “manage feature development”, branches that “help build releasable code”, branches that “conveniently fix key bugs in releases”, and so on.

6

The main feature of the auxiliary branch is that it has a “very limited life cycle” and can be eliminated after completing its mission.

7

I suggest that at least three types of “auxiliary branches” should be set up, which we call “Feature branches”, “Release branches” and “Hotfix branches”.

At this point, we have formed the following most important organization group, consisting of two bold branches (Master /develop) and three fine branches (feature/release/hotfixes).

8

“Feature branches”, originating in and eventually belonging to Develop.

9

Feature branches are often used to develop new independent features, and these branches inevitably end up merging into the “Develop” branch or being abandoned. The most typical “Fearture branches” must exist in team developers, not in “central repository”.

10

The term “Feature branches” derives from “Develop” branches, and its implementation methods are as follows:

git checkout -b myfeature develop

11

Feature branches are also classified as “Develop” branches, which are implemented in the following ways:

Git checkout DevLeopgit merge –no-ff myfeature (–no-ff, not fast forward) Git merge commit –no-ff git merge commit — git merge commit — git merge commit Git branch -d MyFeaturegit Push Origin develop git Branch -d MyFeaturegit Push origin develop

12

“Release Branch”, originating from the Develop branch and eventually going to the “Develop” or “master” branch. The recommended name for this branch is “Release -*”

13

Relase Branch is usually responsible for “short-term pre-release preparations,” “minor bug fixes,” and “preparation of meta information such as version numbers.” Meanwhile, the “Develop” branch is ready to work on the next new feature.

14

The best time for Release Branch to generate new commits is when the “Develop” branch has basically reached its desired state, or at least the new features have been completely merged from “Feature Branches” into the “Develop” branch.

15

Create “Release Branches”, use the following methods:

Git checkout -b release-1.2 develop./bump-version.sh 1.2 git checkout -b release-1.2 develop. Git commit -a -m “bump version number to 1.2”

16

We can continue to fix bugs on “Release Branches” for a short time. At this stage, new features are prohibited from being incorporated; they should be merged into the “Develop” branch.

17

After a number of bug fixes, codes on “Release Branches” have reached the releasing state. At this point, three actions need to be completed: First, merge “Release branches” into “Master” branches. Second, be sure to TAG the new submission on master. Third, merge “Release branches” back into “Develop” branches.

Git checkout mastergit merge –no-ff release-1.2git tag -a Git checkout developgit merge –no-ff release-1.2 Git branch -d release-1.2

18

“Hotfix branches” derives from “master”, attributed to “develop” or “master”, often named “Hotfix -*”

19

“Hotfix Branches” is similar to “Release Branch”, but generating this branch is always an unexpected key BUG.

20

The reason for the recommendation of “Hotfix Branches” was to avoid the situation where the development of new features of “Develop branches” had to make way for BUG fixes.

21

The establishment of “Hotfix Branches” has been carried out in the following ways:

Git checkout -b hotfix-1.2.1 master./bump-version.sh 1.2.1git commit -a -m “Bumpt version to 1.2.1” git checkout -b hotfix-1.2.1 master Commit -m “Fixed severe production problem” (commit a second time after the problem is Fixed)

22

After BUG fixes, merge “Hotfix branches” back to “Master” branch, and merge “Develop” branch as well.

Git checkout mastergit merge –no-ff hotfix-1.2.1git tag -a 1.2.1git checkout developgit merge –no-ff hotfix-1.2.1git tag Branch – d hotfix – 1.2.1

23

Remember the big picture at the beginning of this article? I suggest you download it from here, print it out, and paste it on the wall of your writing desk.

over~

The «The last:
Is “quality in the build process”?



» Next up:
Revisit the Master Classic: Martin Fowler’s Continuous Integration

Hot articles in software engineering

Latest articles in software engineering

The latest news

Hot news