版本控制与常见的分支模型

一直为软件版本发布困扰，开发人员需要不断前进完成功能，测试人员在后面紧跟测试，售后人员需要稳定版本上线，三者间没有达成统一的认识，产品或者项目到底怎样才算稳定版本。

目前公司配置管理在策略上采用的是不稳定主干（unstable trunk） 模式，所有的项目都在同一主干上进行修改，在每次上线后并没有明确的stable分支版本，基本上是靠测试人员TAG代码来管理维护的。

问题：

   1）、多个项目组开发人员都可能并发对同样代码进行修改，造成了严重的代码冲突问题。例如张三修改了a.java并上QA测试服务器，在QA测试过程中， 李四也对a.java进行修改并上QA，李四的代码覆盖了张三的代码。由于是SCM人员并不清楚代码冲突情况，这样张三和李四的代码上QA很容易相互影响 并很难查具体原因

   2）、由于没有明确stable分支版本，导致上QA、上生产只能采用增量更新，上QA、上生产出问题后的代码回滚很麻烦，严重影响了测试、上线效率。对于生产环境运行的代码的具体版本并没有明确的管理，导致生产系统出问题后要排查问题也很难查。

   3）、由于核心基础包没有与上层应用隔离，导致大家都会对核心包进行修改，修改后代码质量并没有有效控制。于是出现因为修改基础包影响整个系统功能等现象

如何避免，至少要从如下几个方面来：

  1）、分支管理策略：采用适当的分支管理策略来保证开发库、测试库、发布库的隔离

  2）、适当引入每日编译、持续集成、Code Review等敏捷开发的最佳实践

  3）、采用自动化脚本完成上QA、上生产的部署工作，避免人工失误

  4）、对核心框架、后台应用、前端页面开发采用不同的配置管理策略

版本管理的策略：不稳定主干策略、稳定主干策略、敏捷发布策略。

下面是对这几种策略的摘录：

不稳定主干策略

1. 使用用主干作为新功能开发主线，分支用作发布。
2. 被广泛的应用于开源项目。
3. 比较适合诸如传统软件产品的开发模式，比如微软的office等。
4. bug修改需要在各个分支中合并。
5. 新代码在主干上开发，因此如果主干不能达到稳定的标准，就不可以进行发布。
6. 这种策略的好处是没有分支合并的工作量，因此比较简单。

稳定主干策略

1. 使用主干作为稳定版的发布。
2. bug的修改和新功能的增加，全部在分支上进行。
3. 不同的修改或新功能开发以分支隔离。
4. 分支上的开发和测试完毕以后才合并到主干。
5. 主干上的每一次发布都做一个标签而不是分支。
6. 每次发布的内容调整起来比较容易。
7. 缺点是分支合并所增加的成本。

敏捷发布策略

1. 敏捷开发模式的项目中广泛采用，敏捷开发的项目具有固定的发布周期。
2. 为每个task建立分支。
3. 为每个发布建立分支，每个周期内的task分支需要合并到发布分支发布。
4. 在完成发布后，发布分支的功能合并到主干和尚在进行的任务分支中。
5. 一种稳定主干策略的变体。
6. 团队成员要求较高。

团队当前情况

1. 负责互联网产品的开发，发布更新较为频繁。
2. 有固定的发布周期，同时也存在比较多的hotfix。
3. 修改任务通常比较小，改动范围通常不大，时间通常较短。
4. 不同的功能页面有不同的小组负责，耦合度相对较低。
5. 团队目前没有采用分支策略，开发人员协商进行增量更新，出现错误的几率较高。
6. 已使用SVN版本控制工具。

初步实践

参考上述策略，结合当前团队的现状，初步设计了下面的版本控制解决方案。

此方案已稳定主干策略为主结合了一些敏捷发布策略的思路，具体实施方案如下：

1、主干时刻处于稳定状态，随时可以发布。设SCM人员对主干代码进行管理，普通开发人员只读。

2、SCM为开发任务建立开发分支。常规的可以以小组为单位建立分支，较大的任务可以建立专门的分支。

3、在发布日，从主干复制一个测试分支，需要在本发布日发布的各开发分支向此测试分支合并。

4、对测试分支代码进行测试，出现bug在测试分支上更改，无误后发布。

5、测试分支代码发布后，合并入主干，并在主干上进行标记。

6、对紧急修复（Hotfix）的情况，可以从主干复制出测试分支，在测试分支上进行紧急修改，并在测试后发布，发布后同样将代码合并会主干，做标记。

7、 Hotfix仅限于可以很快解决的小问题，如果更改时间过长，则需采用常规方法完成。

8、如果在测试分支测试过程中需要hotfix工作，则在复制一个新的测试分支进行hotfix，测试后发布。然后同时合并入原测试分支和主干，并在主干上做标记。此过程未在上图中画出。

9、测试分支发布后，开发分支可以删除；测试分支合并入主干后，测试分支可以定期删除。

方案的优缺点

方案优点

1、解决了没有实施分支策略时，代码不能经常签入的问题。

2、主干代码始终处于稳定的状态随时可以发布，降低了风险。

3、可以基于一个完整的测试分支进行测试及发布，而不是以口口相传的方式增量更新。

方案缺点

1、建立分支、合并分支增加了工作量。考虑实际情况，以及版本控制工具的辅助，增加的工作量应该可以接受。

2、如果某些开发分支工期跨越多个发布周期，修改过于剧烈，合并分支时可能工作量较大。可以考虑分解任务，避免过大的任务出现。

3、在同一时间最好只有一个测试分支，因此建立测试分支的权限需要限制，除hotfix场景外应当避免。

转自 ：http://blog.csdn.net/huaishu/article/details/40511303