Ey&PYfZf3TwU0 这几天在网上查询了一些资料,了解到比较常见的版本控制分支策略有三种:不稳定主干策略、稳定主干策略、敏捷发布策略。51Testing软件测试网TtL'I,| S
MTR?$ie0 下面是对这几种策略的摘录:
M+x9S#w T(H&x^g051Testing软件测试网A}_+R@$q&QgP
D.Y 不稳定主干策略
;Er~a6@"_0
3K}s Q9Flz!F d|6l0 使用用主干作为新功能开发主线,分支用作发布。
'p`x:c5clEy0 被广泛的应用于开源项目。51Testing软件测试网f3CB{LWu#{B
比较适合诸如传统软件产品的开发模式,比如微软的office等。51Testing软件测试网,pgd JI'?JeO
bug修改需要在各个分支中合并。
j%LSP)Ja Fz0 新代码在主干上开发,因此如果主干不能达到稳定的标准,就不可以进行发布。
6x v7FmFW1B0 这种策略的好处是没有分支合并的工作量,因此比较简单。51Testing软件测试网,O-X&XS0h
稳定主干策略51Testing软件测试网kF,H ?m"Se$`
51Testing软件测试网9}oA5sR(V
f
使用主干作为稳定版的发布。51Testing软件测试网.|;r'p$mL#IA
bug的修改和新功能的增加,全部在分支上进行。
Hsi^Z,d;uq v0 不同的修改或新功能开发以分支隔离。51Testing软件测试网0]i&l"DxA
分支上的开发和测试完毕以后才合并到主干。51Testing软件测试网qVU)XU.i(ys%c
主干上的每一次发布都做一个标签而不是分支。
"Y
D`/e k4V$^{u'~0 每次发布的内容调整起来比较容易。51Testing软件测试网0yW*I0O)_U
缺点是分支合并所增加的成本。
O9J7G1``0 敏捷发布策略51Testing软件测试网&n:K RQ#F8Bo@
j;jQ5}k*sH0 敏捷开发模式的项目中广泛采用,敏捷开发的项目具有固定的发布周期。51Testing软件测试网;[Q] E%UZzSF9T
为每个task建立分支。51Testing软件测试网u C1{ NYr
Vq
为每个发布建立分支,每个周期内的task分支需要合并到发布分支发布。
M3q$HUk?%qM{0 在完成发布后,发布分支的功能合并到主干和尚在进行的任务分支中。
3M+mG@\{4Iy0 一种稳定主干策略的变体。51Testing软件测试网{'FV;Ty2W/O!D
团队成员要求较高。
*W4`&LC'W:vj051Testing软件测试网2n7}(fJ4H-Qg 团队当前情况51Testing软件测试网U X @?
z'V0_a
51Testing软件测试网u1Os&`PW!BV 负责互联网产品的开发,发布更新较为频繁。
3J?~^+P051Testing软件测试网dA.DC!|[ 有固定的发布周期,同时也存在比较多的hotfix。51Testing软件测试网
Q,x}:\%G8iU
*Bk@2@6v*P5Z"r0 修改任务通常比较小,改动范围通常不大,时间通常较短。
3L#r:[W/]$L!pf;w/A051Testing软件测试网:n*MQ @&lC 不同的功能页面有不同的小组负责,耦合度相对较低。
0y+v3Y~n!g0@7et7pKhqm%}0 团队目前没有采用分支策略,开发人员协商进行增量更新,出现错误的几率较高。51Testing软件测试网Zf$q7f A
@cd {u_
51Testing软件测试网^Ti R*Z(I}| ?P 已使用微软TFS做为版本控制工具,可以更充分的挖掘使用TFS的分支功能。
%U?4U:{sTn0:B.~%jx[t0 我的初步实践
f#oh}-|051Testing软件测试网2O,eZLn5U 参考上述策略,结合当前团队的现状,我初步设计了下面的版本控制解决方案。
tH]]7?fA051Testing软件测试网Gt/^maX?q*o
此方案已稳定主干策略为主结合了一些敏捷发布策略的思路,具体实施方案如下:
W,ej
s.M0 1、主干时刻处于稳定状态,随时可以发布。设专门人员对主干代码进行管理,普通开发人员只读。51Testing软件测试网5Ld%T)g8\4ga1O3i/w
2、为开发任务建立开发分支。常规的可以以小组为单位建立分支,较大的任务可以建立专门的分支。51Testing软件测试网ql1Ah$uc6wv/O
3、在发布日,从主干复制一个测试分支,需要在本发布日发布的各开发分支向此测试分支合并。
"H9Wk7~$Y~0 4、对测试分支代码进行测试,出现bug在测试分支上更改,无误后发布。
8r'N)`XA0 5、测试分支代码发布后,合并入主干,并在主干上进行标记。51Testing软件测试网
h5[K
e$x}j^7y
6、对紧急修复(Hotfix)的情况,可以从主干复制出测试分支,在测试分支上进行紧急修改,并在测试后发布,发布后同样将代码合并会主干,做标记。
GZ6bI+K_qG0 7、 Hotfix仅限于可以很快解决的小问题,如果更改时间过长,则需采用常规方法完成。
5J{(C3xt0| sv0 8、如果在测试分支测试过程中需要hotfix工作,则在复制一个新的测试分支进行hotfix,测试后发布。然后同时合并入原测试分支和主干,并在主干上做标记。此过程未在上图中画出。51Testing软件测试网istWI'c!eq{
9、测试分支发布后,开发分支可以删除;测试分支合并入主干后,测试分支可以定期删除。51Testing软件测试网-I%o9S.QzNRH"\#wGM
方案的优缺点51Testing软件测试网 aSS7e%?-O6y
方案优点
Z)V8E.dG|T X!IG0 1、解决了没有实施分支策略时,代码不能经常签入的问题。51Testing软件测试网#u
Dd'SlVAV
2、主干代码始终处于稳定的状态随时可以发布,降低了风险。
6Ag@oA7w*E7W!a0 3、可以基于一个完整的测试分支进行测试及发布,而不是以口口相传的方式增量更新。
H]A#IC%n0 方案缺点51Testing软件测试网(Fl:hh1uxO8\vT
1、建立分支、合并分支增加了工作量。考虑实际情况,以及版本控制工具的辅助,增加的工作量应该可以接受。51Testing软件测试网i2Z!f8?#m9Yc
2、如果某些开发分支工期跨越多个发布周期,修改过于剧烈,合并分支时可能工作量较大。可以考虑分解任务,避免过大的任务出现。51Testing软件测试网G+c3V#?4@(n |THk
3、在同一时间最好只有一个测试分支,因此建立测试分支的权限需要限制,除hotfix场景外应当避免。
!HU;r*y1[u%PY(d0