1 分支管理与策略
在项目开发中考虑分支策略时，我们要考虑几个问题：
- 什么情况下我们需要创建分支?
- 主干应该是保持什么样的原则? 做什么用
- 不同类型的项目开发,如何进行分支创建?
-
bugfix 等日常的维护应该如何进行?
作者：xuejiang 2007-11-07 14:42 2 回复：分支管理与策略
技术操作： cvs 中可以在一个源码文件上直接创建分支。 在 vss 中先将文件 share 到一个目录，再断掉连接就变成 branch 了。 svn 明显是吸收了 vss 的做法，以目录命名的形式来区分分支、标签、主干三种形式，实际操作就是一个 copy。
流程： 流行的几种做法有： 1、程序员在分支上开发，发布的合并过程在程序员那里完成，合并完成之后，程序员会 commit/checkin 到主干上，然后文件列表发给发布人员。发布人员在主干上根据文件列表进行 up，不允许 up 全部代码。然后由发布人员根据自己工作空间的版本打一个标签，形成一个新的基线。
这样做的好处是合并比较方便，但时间长了，主干就可能变得不可信，只有标签才可信。因此需要定期对主干进行一次全编译，全面测试。这种模式可以在版本较稳定的维护阶段进行。
2.程序员在分支上开发，自己测试通过后，通知发布人员分支名字，由发布人员来合并到主干。这样合并产生的冲突需要程序员在发布之前的编译环境来处理。任何主干修改的动作只有发布人员/集成员才能做。
这样可以保证主干一直是好的，随时都是与产品环境的代码一致，但，合并比较麻烦，如果发生冲突需要程序员到编译环境进行处理，合并工作量比较大。
3.开发人员在开发分支上进行开发.配置管理员每周打一个发布分支，如果程序员需要发布，就将自己的代码提交到发布分支。配置管理员利用 fisheye（Java 代码覆盖工具 Clover 提供商 www.cenqua.com/fishye 发布的）可以获得文件列表，然后每周定期进行代码合并。如果出现冲突跟第 2 种做法一致.
这种方法和第 2 差不多，但统一了合并时机，批量处理，效率比第 2 种高。适用于产品不稳定的时候，分支任务比较多的时候（根据产品模块情况，可能一个任务每周就一个分支）。
作者：xuejiang 2007-11-07 15:15 3 回复：分支管理与策略
那么什么情况下我们需要创建分支呢？
情景 1：快要发布一个新版本了，一个开发人员的小分队可能就要去为软件的这次发布做好准备，如修正一些收尾的 bug，与发布工程师一起工作、为 QA 团队提供帮助。这个时期，他们需要的是稳定性，如果这时还有其他开发者编辑代码，添加一些预计到下次发布才会包括进去的功能特性的话，他们的努力就会白费。这时就应该创建分支，让其中的一个团队在分支上工作。 那么是发布的团队在分支上还是新功能开发团队在分支上工作呢？ 这有个原则：谁的改动量小、合并方便，谁就在分支上工作。如果大部队是新功能，小分队是发布，这小分队应该在分支上进行签入签出，在发布时创建标签并将修改合并到主干上。
情景 2：团队正在主干上开发下一个版本，处于开发中晚期了，此时客户正在运行的版本陆陆续续发现了一些 bug，需要在某个特定的时候发布一个版本或者补丁解决客户的问题，而承诺给客户的时间又来不及发布新版本，这时候就需要在上个版本的位置创建一个分支，一部分开发员在此分支上解决发现的各个 bug；其余大部队继续在主干上开发新版本。在补丁发布之后再将修改合并到主干上。
注意：要避免过度的分支。像分支上再开分支；或者分支和主干颠倒，大部队在分支上开发，主干只是配置管理员或者集成员在维护/合并。这些做法都是不好的，因为这样会导致分支合并的代价非常高昂。
作者：222.129.219.* 2007-11-16 23:19 4 回复：分支管理与策略
作者：xuejiang 2007-11-16 23:24 5 回复：分支管理与策略
另外，如果要研发的新版本或者新功能有比较大风险，有可能会在开发中途夭折的话，也应该使用分支来开发比较好。当然，这种情况一般很少见。