Gitflow的简单回顾总结
尽管Gitflow有着诸多优点:
- master分支的任何tag都是一个可发布版本
- 在发布候选分支上进行测试,不影响develop分支下一个版本的开发
- 可以方便的将发布候选分支的bugfix和hotfix分支的hotfix合并入develop和master分支
但是它也存在着几个缺点:
- 合并周期太长
- 不支持多版本并行开发(或者说支持的很糟糕,很容易合并错误)
- 适合可预测的版本发布,对不可预测的版本发布支持不友好
Gitflow合并周期太长
合并周期长的缺点就是容易发生合并冲突,或者说发生合并冲突后解决问题困难。
我们在使用其它branching model的时候也需要注意这一点,要缩小提交的粒度,增加提交的频率。尤其是多人协作开发同一部分功能的时候。这样及时有合并冲突,我们也能及时发现,修复的成本也最低
Gitflow合并周期长的几个节点:
- feature branch合并入develop分支(这个可以人为地缩小feature branch来减小合并冲突的scale)
- release candidate分支合并入develop分支和master分支(此两处合并周期最长,合并冲突风险大)
- hotfix分支比较短小,合并周期一般小一些
release candidate分支在几轮rc测试,bugfix后合并入develop分支,时间较长,发生冲突概率大,解决冲突的成本大。
release candidate分支在合并入develop分支后还需要合并入master分支,这个时间算上在develop分支上开发feature的时间就更长了(虽然我们不直接往master分支上提交feature,可以认为合并入master分支发生合并冲突的概率和成本跟合并入develop分支一样)。
Gitflow不支持多版本并行开发
从Gitflow的流程图可以看到它支持future feature的开发,也就是支持多版本并行开发。但是实践证明Gtiflow在多版本并行开发上表现的很糟糕。
Gitflow每个release版本的feature都是在develop分支上进行开发,举例来说v1.1 v1.2,只有在v1.1发布后或者最少进入到rc阶段后才可以在develop分支上开发v1.2的feature。从develop分支上看多版本(小版本迭代)的开发是串行的。
当然也可以进行多个版本的并行开发,譬如v1.1 v2.1
- 我们在开发完v1.1后需要开发v2.1-
- 由于v2.1的开发周期太长,v2.1开发的同时我们还需要开发v1.2 v1.3 v1.4 …
- 此时我们可以在develop分支上检出一个v2.1分支,v2.1的feature往v2.1分支上提交
- 等v1.x freeze后,将v2.1分支合并入develop分支。
这样在合并后develop分支同时具有了v1.x的feature和bugfix以及v2.1的feature。问题是v2.1的合并周期太长,合并的风险非常大,解决起来的成本也将非常大。
对不可预测的版本发布支持不友好
Gitflow流程上的约束,当下一个版本发布后,上一个版本就会被freeze,譬如:
- sdk_v1.2发布后,sdk_v1.1就被freeze了
- 假如客户当前用的是sdk_v1.1.3,现在发现了一个bug
- 客户希望我们发布patch给它们,也就是提供sdk_v1.1.4
- 由于sdk_v1.2已经发布,sdk_v1.1被定格在了sdk_v1.1.3,因此不能发布sdk_v1.1.4
- 只能在sdk_v1.2.1上进行修复,然后提供给客户sdk_v1.2.2。