|
|
@@ -8,13 +8,13 @@
|
|
8
|
8
|
|
|
9
|
9
|
眼下最流行的"版本管理系统"，非[Git](http://git-scm.com/)莫属。
|
|
10
|
10
|
|
|
11
|
|
-
|
|
|
11
|
+
|
|
12
|
12
|
|
|
13
|
13
|
相比同类软件，Git有很多优点。其中很显著的一点，就是版本的分支（branch）和合并（merge）十分方便。有些传统的版本管理软件，分支操作实际上会生成一份现有代码的物理拷贝，而Git只生成一个指向当前版本（又称"快照"）的指针，因此非常快捷易用。
|
|
14
|
14
|
|
|
15
|
15
|
但是，太方便了也会产生副作用。如果你不加注意，很可能会留下一个枝节蔓生、四处开放的版本库，到处都是分支，完全看不出主干发展的脉络。
|
|
16
|
16
|
|
|
17
|
|
-
|
|
|
17
|
+
|
|
18
|
18
|
|
|
19
|
19
|
[Vincent Driessen](http://nvie.com/)提出了一个分支管理的[策略](http://nvie.com/posts/a-successful-git-branching-model/)，我觉得非常值得借鉴。它可以使得版本库的演进保持简洁，主干清晰，各个分支各司其职、井井有条。理论上，这些策略对所有的版本管理系统都适用，Git只是用来举例而已。如果你不熟悉Git，跳过举例部分就可以了。
|
|
20
|
20
|
|
|
|
@@ -22,7 +22,7 @@
|
|
22
|
22
|
|
|
23
|
23
|
首先，代码库应该有一个、且仅有一个主分支。所有提供给用户使用的正式版本，都在这个主分支上发布。
|
|
24
|
24
|
|
|
25
|
|
-
|
|
|
25
|
+
|
|
26
|
26
|
|
|
27
|
27
|
Git主分支的名字，默认叫做Master。它是自动建立的，版本库初始化以后，默认就是在主分支在进行开发。
|
|
28
|
28
|
|
|
|
@@ -30,7 +30,7 @@ Git主分支的名字，默认叫做Master。它是自动建立的，版本库
|
|
30
|
30
|
|
|
31
|
31
|
主分支只用来分布重大版本，日常开发应该在另一条分支上完成。我们把开发用的分支，叫做Develop。
|
|
32
|
32
|
|
|
33
|
|
-
|
|
|
33
|
+
|
|
34
|
34
|
|
|
35
|
35
|
这个分支可以用来生成代码的最新隔夜版本（nightly）。如果想正式对外发布，就在Master分支上，对Develop分支进行"合并"（merge）。
|
|
36
|
36
|
|
|
|
@@ -48,11 +48,11 @@ Git创建Develop分支的命令：
|
|
48
|
48
|
|
|
49
|
49
|
这里稍微解释一下，上一条命令的--no-ff参数是什么意思。默认情况下，Git执行"快进式合并"（fast-farward merge），会直接将Master分支指向Develop分支。
|
|
50
|
50
|
|
|
51
|
|
-
|
|
|
51
|
+
|
|
52
|
52
|
|
|
53
|
53
|
使用--no-ff参数后，会执行正常合并，在Master分支上生成一个新节点。为了保证版本演进的清晰，我们希望采用这种做法。关于合并的更多解释，请参考Benjamin Sandofsky的[《Understanding the Git Workflow》](http://sandofsky.com/blog/git-workflow.html)。
|
|
54
|
54
|
|
|
55
|
|
-
|
|
|
55
|
+
|
|
56
|
56
|
|
|
57
|
57
|
**三、临时性分支**
|
|
58
|
58
|
|
|
|
@@ -74,7 +74,7 @@ Git创建Develop分支的命令：
|
|
74
|
74
|
|
|
75
|
75
|
第一种是功能分支，它是为了开发某种特定功能，从Develop分支上面分出来的。开发完成后，要再并入Develop。
|
|
76
|
76
|
|
|
77
|
|
-
|
|
|
77
|
+
|
|
78
|
78
|
|
|
79
|
79
|
功能分支的名字，可以采用feature-*的形式命名。
|
|
80
|
80
|
|
|
|
@@ -127,7 +127,7 @@ Git创建Develop分支的命令：
|
|
127
|
127
|
|
|
128
|
128
|
修补bug分支是从Master分支上面分出来的。修补结束以后，再合并进Master和Develop分支。它的命名，可以采用fixbug-*的形式。
|
|
129
|
129
|
|
|
130
|
|
-
|
|
|
130
|
+
|
|
131
|
131
|
|
|
132
|
132
|
创建一个修补bug分支：
|
|
133
|
133
|
|
E_wsq
