Question

版本管理策略是一个很古老的话题。业界关于这个话题的介绍不胜枚举。这里，我的讨论只限于App版本管理策略。App的独特之处在于：

首先，App是一款软件，而不是网站。所以，每次只能通过发布一个新版本的App，来增加新功能和修复bug，而网站当天修复bug当天上线。这其实是CS和BS的区别。

其次，App因为目前的受众人群多，动则上亿的用户群，所以这就要求App的发版周期多，可以大约2周发一次新版本。这区别于传统软件慢条斯理的迭代周期。

基于上述这两点，App的版本管理策略与以往其他项目都不同。本章和第10章都将围绕这个主题而展开讨论。

8.1.1　三种版本管理策略

无论是SVN还是GIT，都有主干（Trunk），有分支（Branch）。相应的版本管理策略就有3种：

1）分支开发，分支上线。

2）主干开发，主干上线。

3）主干开发，分支上线。

策略1： 分支开发，分支上线。我带团队的时候，曾经使用过这种策略。就是说，每次迭代开始，就打一个分支，接下来一个月的迭代工作，包括开发和测试，全都在分支上进行。迭代期间，看起来没啥事，一切正常。等上线后，往主干上合并代码可就麻烦了，改了那么多文件，几千处需要合并的地方，自动合并功能我是从来不敢太相信的，一个个文件手动合并又没有时间，所以我只好把主干上的代码全都删除了，然后把分支上的代码一次性粘贴到主干上，直接签入代码。

这样做最大的问题就是，主干长时间没有嵌入，成了摆设；另一个问题是代码文件的修改历史不连贯，要到各个分支上去看。

策略2： 主干开发，主干上线。就是说，我们总是在主干上进行开发和测试。只要是本期迭代的需求，都是这么操作，直到发版上线。

策略3： 主干开发，分支上线，就是说，在主干上开发，直到写完代码，然后开分支，在分支上测试和修bug，直到上线，最后再合并回主干，这样做的好处是要合并的代码并不多，如图8-1所示。

图8-1　主干开发、分支上线的版本管理策略

策略2和策略3没有孰好孰坏的说法。下面详细介绍这两种常见的版本管理策略。

场景1：

版本策略：主干开发，主干上线。

使用工具：SVN

迭代周期：4周

所有开发人员都在主干上进行开发，测试也是在上面进行，直到有一天，项目经理说，我们要发版了。于是大家手忙脚乱地在主干上修改bug，直到所有人都满意了，然后基于这个点——对应SVN某次提交的ChangeSet，组织发版工作。之后，我们会基于这个点打一个Tag，需要强调的是，一定要在注释中注明是基于哪个ChangeSet。

SVN没有真正的分支和Tag，所谓的打Tag工作，就是基于某次提交，把代码复制一份放在一个新的目录下面。分支也是如此。

场景2：

版本策略：主干开发，分支上线。

使用工具：GIT

迭代周期：1~2周

迭代周期短，就会经常发生上轮迭代还没完成，下轮迭代就要开始了的情况。于是我们留一小撮人去收拾上轮迭代的遗留问题，大部队还是要在主干上进行下轮迭代的开发工作。

为此，我们要为这一小撮人开一个新的分支，让他们在上面工作，直到上一轮迭代发版上线，然后再把代码改动合并到主干上。

这样，我们就在分支上发版，并在分支上打Tag。

GIT比较适合干这种分支间合并代码的技术活儿，GIT中有一个Cherry Pick的功能，就是干这事的。此外，GIT中的Tag就是一个指针，所以不必担心又折腾出一套冗余代码的事情。

对比这两种场景，我们发现，版本管理工具的选择对选择使用哪种策略有一定的影响。SVN本身的局限性导致了合并代码时心里会没底，需要更多的回归测试时间。

另一方面，迭代周期的长短，对使用哪种策略也有影响，尤其是项目周期发生重叠的时候。

8.1.2　特殊情况的版本管理策略

特殊情况1： 有时候，有些需求，我们发现开发有时间但是测试没有时间了，只能放到下期迭代进行，我们就在主干上找一个相对稳定的点，基于这个点开一个新分支，专门用来做这个需求，等本次迭代结束后，我们立刻就把这个分支上的功能合并到主干上，这样测试团队也可以马上测试该功能了。新分支的命名规则要规范好，能一眼看出它的功用，比如DevForLoginBaseOn20140909，一看就知道是为了Login这个新需求而基于2014年9月9日打的分支。

特殊情况2： 接下来说到定制渠道包和手机预装的版本管理策略。如果只是简单的修改渠道号，是不需要执行版本管理策略的。但是，经常有些渠道，他们会要求我们的App换个闪屏页。对于在某款手机上做预装，就更麻烦了，手机厂商也会有测试人员，他们会检查我们的App里面的一些bug，勒令我们修复。我们的版本管理测试是，在发给厂商的那个版本对应的Tag上，比如release1.1.0，创建一个新分支，专门用于做这些小改动，测试团队验收后，打包发给渠道商和预装商。这个分支的命名规范是channel BBB base on release1.1.0，其中BBB为渠道名。

特殊情况3： 最后就是上线后发现重大bug，需要hotfix并紧急上线的版本管理策略。比如说我们发布了版本1.1.0，然后发现该版本有重大问题，需要紧急修复并上线。我们会在release1.1.0这个Tag上新建一个分支，命名为Hotfix base on Release1.1.0，我们在这个分支上修bug、测试并发hotfix版本1.1.1。发版后，我们基于这个hotfix分支的稳定节点打一个新的Tag，比如release1.1.1。