这本书是《软件配置管理策略和IBM Rational ClearCase》（第二版），中文版is coming soon... ^-^

下面是开发分支和集成分支的一些典型使用：
1．每个活动/任务设一个开发分支
每个开发任务以先隔离开发再归并/集成到集成分支的方式进行，通常这之后会生成一个新的发行版本。也就是说每个开发人员根据他承担的任务进行隔离。这种方法非常类似于ClearCase UCM基于任务的方法（见本章稍后“使用UCM进行集成”部分）。但不同于UCM之处在于，它使用分支来记录变更集。如果您真地希望这样，也可以用ClearCase UCM实现这一策略，将开发流限制为只包含一个活动。
2．每个开发人员设一个开发分支
每个开发人员的工作通过一个私有的分支进行隔离。当开发人员完成一个任务时，他或她就将变更归并到集成流。开发人员继续使用这个开发流来完成下一个任务。与每个任务设一个分支的方法相比，这种方法的优点在于需要创建的分支较少。这种方法的不足之处在于，分支不记录任务的变更集，变更集必须用其他的方式来记录。这种方法类似于在传统并行项目中使用ClearCase UCM开发流。不同的是UCM提供了内建的活动来记录任务的标题和变更集，活动与完成任务的分支是独立的。
3．每个主要特性/子项目设一个开发分支
每个主要特性或子项目均可在各自的分支上进行开发。这种情况不同于基于活动的分支方法，这里有一个小型团队工作在某一特性或一组相关特性上，该团队通过使用分支/最新版本方法来开发这个主要特性。与基于活动的分支方法类似，存在一个集成分支，它代表一个发行版本，特征在这里进行归并和集成。ClearCase UCM具有灵活的流继承层次，可以通过包含将来工作的子集成开发流来对提供这种策略的模型。这些子集成流最终将交付到UCM项目的集成流中。
4．每个晋升级别设一个集成分支
在这种方法中，每个晋升级别存在一个分支。例如，在一个具有三层晋升级别的发布版本中，可能会有一个“开发”分支、一个“集成”分支以及一个“产品”分支。这种方法的优点是可以在分支上施加控制，允许不同组织的用户组来控制不同的分支。例如，一个测试组可以控制集成分支并仅允许开发分支上经过“审批”的变更归并到该集成分支。
这种分支方法模拟了一种传统的SCM方法—为软件系统准备不同的副本并将文件从系统的一个副本移到下一个副本。这种分支方法也是许多公司在实现源代码升级时所采用的方式。
本方法的另一个优点是，通过使用图形化的元素版本树浏览器可以非常容易地确定代码的质量级别。这种方法的缺点是文件内容必须从一个晋升级别归并到另一个晋升级别，即使在这些晋升级别之间文件并未发生改变。这种拷贝式的归并可能很花时间，效率不高，可能导致对没改变过的文件创建新的版本。ClearCase UCM提供了基线来实现晋升级别。通过注明只读的流，它也支持这种策略的一个稍有不同的变种。这些类型的流在对发行版本开发过程中的产品、进阶和其他质量水平建立模型时是有用处的。通过将这些流变基到相应的基线，相应的配置就能呈现在与流相关的视图中，无需前面提到的那种拷贝式归并。这种策略在第10章中将进一步探讨。
5．每个发行版本设一个集成分支
这种方法使用了经典的分支依据。通过对每个发行版本隔离其分支上变更，从而同时支持多个发行版本的并行开发。最常见的例子是在一个已有分支上进行维护工作，与此同时继续进行下一个发行版本的开发工作。这样公司就可以在发布一个次要或修订发行版本的同时继续进行主要发行版本的工作，因此这种方法提供了团队之间的隔离。
这种方法的缺点在于，维护版本与开发版本之间的集成必须提前进行计划，否则很可能在主要版本的开发周期接近结束时发生。由于集成问题可能较晚才能被发现，因此这种“大爆炸”式的集成方法可能造成主要发行版本的严重延误。为了避免这一问题，在开发主要发布版本时应及早进行集成点的计划。例如，可以计划在软件的alpha版本同现有的维护工作进行集成，然后在软件的beta版再集成一次，这样当您得到最终的发布版本时，主要的集成问题应该已经解决了。
6．每个发行版本设一个活动开发集成分支
这种方法是解决开发团队和SCM团队之间的典型冲突的一种方式。开发团队通常希望使用最近检入的能够成功构建的内容，作为后续开发活动的基础；而SCM团队通常只希望使用稳定的、基线化的构建版本，作为变更的基础。将发布集成分支一分为二（一个给SCM团队，一个给开发团队），这使得SCM团队可以使用发布集成分支来完成不太频繁但更为稳定的集成和确定基线的活动，同时让开发团队能够更频繁、节奏更快地构建和集成。
这种方法的好处在于，SCM可以选择哪个开发基线适合纳入到发布集成分支。开发团队必须负责确保其活动开发集成分支的完整性和一致性。这种方法的不足之处与晋升分支类似：需要将文件从活动开发集成分支拷贝归并到发布集成分支。通过灵活的流继承层次，ClearCase UCM可以为这种策略建立模型，让开发团队根据需要在集成流上工作。SCM团队可以周期性地将构建流变基至UCM项目集成流的相应开发基线。
7．主线集成分支
一个常见的分支错误是对每个发布集成分支，都让它从前一个发布版本中分支出来，形成连续的阶梯状结构。这可能很快导致很深和很广的分支树形结构，需要额外的归并工作才能让最初的变更集传递（propagate）到多个版本中去。这还可能创建非常长的分支路径名，最后需要进行“清理”。
主线集成分支是一个层次结构的顶层分支，帮助协调和同步并行发布版本中的工作，在传递变更时使得归并工作的复杂性降到最低。与从前一发布版本分支中分出后续发布版本分支的做法不同，前一版本的分支被归并到主线（这个过程常被称为主线化），新的分支从主线中创建出来，对以前的发布版本提供维护和支持。
这种方法的好处在于，它让“最近在开发”版本的开发工作保持在同一个集成分支，因此维护的并行发布版本分支较少，现存发布版本分支之间的演化距离也更小一些。它也避免了连续阶梯问题的缺点。UCM有一个等价的策略利用了主线项目，这在第7章中已进行了讨论。
8．每个补丁设一个开发分支
另一个常用的分支依据是补丁处理。一个“补丁”是对正式发布版本中某个缺陷的修复，它可以单独地应用于该发布版本上，形成给定正式版本的一个派生版本。所以，它与基于活动/任务的分支方法类似。
通过在其自己的分支上开发一个补丁，您就可以在不同时间将补丁集成到多个发布版本中，这只需将补丁从补丁分支归并到发布版本分支即可。这使得开发人员不必一次又一次地进行手工变更就可以将变更应用到发布版本上。
9．每个补丁集设一个开发或集成分支
补丁集（patch bundle）是一组作为整体进行加入的多个补丁。微软公司的服务包（Service Packs）即是针对其操作系统的补丁包的一个好例子。如果所有的补丁均由一个团队统一开发，那么补丁包分支将可能成为一个开发分支，具体方法与“每个主要特性设一个开发分支”的策略类似。如果所有的补丁由相互独立的不同分支进行开发（使用“每个补丁设一个开发分支”的策略），然后被归并到一个补丁包分支上，那么该补丁包分支将是一个集成分支。这些补丁包就象补丁分支一样，应该在开发周期的适当时间归并到发布版本分支上。
10．每个系统变种设一个集成分支
有时会使用分支来维护系统的不同变种。“变种（variant）”指的是软件系统的某个具体发布版本的轻微修改。例如，将一个系统移植到一个新的操作系统上将产生一个该系统关于一个特定操作系统的变种（如一个软件系统的1.0版可能会有一个Windows变种和一个Unix变种）。也可以使用变种分支来支持同具体客户相关的软件版本。一个软件系统与具体客户相关的一个变种就是针对某个具体客户而对系统进行修改、构建和发布。（在实现具体客户的系统变种时必须小心，因为这类工作需要非常多的资源，必须要单独维护。）
每个变种设一个分支这种方法的主要缺点在于，想要可靠地将变更从一个变种归并到另一个变种非常困难。一般来说，一个变种上仅有部分变更应该被附加到另一个变种上，这意味着从一个变种到另一个变种的每一次归并都必须进行仔细检查，以确定对一个具体的变更是归并它、忽略它，还是在目标变种中以不同的方式对其进行处理。变种分支存在的时间越长，它们彼此间的差距也就越大，也就越难于在它们之间成功地进行归并。一个更好的方法是将系统划分为与变种无关以及与变种有关的构件，然后在构建时对变种部分进行控制。
通常，应该将这里所描述的分支方法组合起来使用以实现一种分支策略。作为对一种分支策略的完整讨论，有必要了解这些分支方法的更多细节。虽然可以用ClearCase来定义您自己的分支策略，但ClearCase UCM模型提供了一种立即可用的方法，在下节中将对此进行描述。