这几天在网上查询了一些资料，了解到比较常见的版本控制分支策略有三种：不稳定主干策略、稳定主干策略、敏捷发布策略。
下面是对这几种策略的摘录：
不稳定主干策略
使用用主干作为新功能开发主线，分支用作发布。
被广泛的应用于开源项目。
比较适合诸如传统软件产品的开发模式，比如微软的office等。
bug修改需要在各个分支中合并。
新代码在主干上开发，因此如果主干不能达到稳定的标准，就不可以进行发布。
这种策略的好处是没有分支合并的工作量，因此比较简单。
稳定主干策略
使用主干作为稳定版的发布。
bug的修改和新功能的增加，全部在分支上进行。
不同的修改或新功能开发以分支隔离。
分支上的开发和测试完毕以后才合并到主干。
主干上的每一次发布都做一个标签而不是分支。
每次发布的内容调整起来比较容易。
缺点是分支合并所增加的成本。
敏捷发布策略
敏捷开发模式的项目中广泛采用，敏捷开发的项目具有固定的发布周期。
为每个task建立分支。
为每个发布建立分支，每个周期内的task分支需要合并到发布分支发布。
在完成发布后，发布分支的功能合并到主干和尚在进行的任务分支中。
一种稳定主干策略的变体。
团队成员要求较高。
团队当前情况
负责互联网产品的开发，发布更新较为频繁。
有固定的发布周期，同时也存在比较多的hotfix。
修改任务通常比较小，改动范围通常不大，时间通常较短。
不同的功能页面有不同的小组负责，耦合度相对较低。
团队目前没有采用分支策略，开发人员协商进行增量更新，出现错误的几率较高。
已使用微软TFS做为版本控制工具，可以更充分的挖掘使用TFS的分支功能。
我的初步实践
参考上述策略，结合当前团队的现状，我初步设计了下面的版本控制解决方案。
此方案已稳定主干策略为主结合了一些敏捷发布策略的思路，具体实施方案如下：
1、主干时刻处于稳定状态，随时可以发布。设专门人员对主干代码进行管理，普通开发人员只读。
2、为开发任务建立开发分支。常规的可以以小组为单位建立分支，较大的任务可以建立专门的分支。
3、在发布日，从主干复制一个测试分支，需要在本发布日发布的各开发分支向此测试分支合并。
4、对测试分支代码进行测试，出现bug在测试分支上更改，无误后发布。
5、测试分支代码发布后，合并入主干，并在主干上进行标记。
6、对紧急修复（Hotfix）的情况，可以从主干复制出测试分支，在测试分支上进行紧急修改，并在测试后发布，发布后同样将代码合并会主干，做标记。
7、 Hotfix仅限于可以很快解决的小问题，如果更改时间过长，则需采用常规方法完成。
8、如果在测试分支测试过程中需要hotfix工作，则在复制一个新的测试分支进行hotfix，测试后发布。然后同时合并入原测试分支和主干，并在主干上做标记。此过程未在上图中画出。
9、测试分支发布后，开发分支可以删除；测试分支合并入主干后，测试分支可以定期删除。
方案的优缺点
方案优点
1、解决了没有实施分支策略时，代码不能经常签入的问题。
2、主干代码始终处于稳定的状态随时可以发布，降低了风险。
3、可以基于一个完整的测试分支进行测试及发布，而不是以口口相传的方式增量更新。
方案缺点
1、建立分支、合并分支增加了工作量。考虑实际情况，以及版本控制工具的辅助，增加的工作量应该可以接受。
2、如果某些开发分支工期跨越多个发布周期，修改过于剧烈，合并分支时可能工作量较大。可以考虑分解任务，避免过大的任务出现。
3、在同一时间最好只有一个测试分支，因此建立测试分支的权限需要限制，除hotfix场景外应当避免。
====================================分割线================================
最新内容请见作者的GitHub页：http://qaseven.github.io/