配置管理分支策略指南

分支策略指南

1. 分支的重要性

在日常的软件开发工作中，项目经常会遇到下面需求：

1、开发新版本的同时，希望能够修改项目早期版本中的某个bug，并在修复后立即发布早期版本的补丁；

2、其它的小组成员为了开发某个功能占有了你希望处理的文件，因为该功能开发时间较长，你希望不要等待他释放后再开发自己的功能，而是同时进行，以便节省开发时间；

3、你所做的工作涉及到许多文件，你希望能够避免经常打乱别人的工作，其他人的工作也不会对你产生影响，而且你可以将所有的工作测试完后再将它们集成到你的项目中。

以上的需求都可以采用并行开发的模式来实现。并行开发能够提升团队协作能力，提高开发效率。但是，并行开发为项目带来好处的同时，也增加了管理的难度，需要一定的过程和方法的支持。

软件分支是软件版本控制、软件构建管理和版本发布管理的重要组成部分，是支持软件并行开发的常用机制。运用分支使得并行开发新的系统、同步更改多个并行版本的错误、同时集成和发布多个版本成为可能。许多版本管理工具，如ClearCase、SVN等，都支持分支。工具为我们解决了大部分并行开发的问题，我们要做的就是根据项目的具体情况，制定适合的分支策略并采用工具来实现。

2. 常见的分支类型及适用场景

软件开发团队经常使用的有几种分支：

2.1.1.组件分支

概念：按照开发组所负责的组件或模块来分，每个小组一个分支；

作用：隔离模块或组件之间的相互影响。模块或组件可单独发布，有独立的发布周期或计划。

适用场景：组件或模块需要单独发布，发布周期不同。

合并或集成策略：每当某个组件发布了新基线或版本，就要进行一次集成。为了保证“尽早并经常集成”，可以通过发布计划等，提高组件发布基线或版本的频率。合并后，分支继续使用。

2.1.2.任务分支

概念：每个开发任务一个分支。例如设立新功能A开发分支，新功能B开发分支等；

作用：隔离开发周期不同的多个功能，避免相互之间的影响，使得并行开发多个功能成为可能，节省开发时间。每个功能可独立合并、测试，降低了集成的难度与风险。

适用场景：对软件质量要求较高，希望新功能可独立测试；多个功能发布时间点不同，希望能够同时开发，节省开发时间；一个任务所要修改的文件，通常与其他任务要修改的文件重叠。

合并或集成策略：一旦完成，该分支就应该被合并到其父分支中，之后该分支就会被废弃掉。

2.1.

3.活动分支

概念：一个变更识别为一个活动，为每个活动创建一个分支。

作用：使得软件能够快速测试、发布针对某个变更的补丁。容易控制软件补丁的质量。

适用场景：每个变更一个分支，管理成本较高，因此常用在需要严格控制变更的软件维护阶段，或变更较少的某个开发、测试阶段。

才

2.1.4.开发分支

概念：未发布的版本使用的分支，只进行“新”的开发；

作用：开发某个发布版的多个新功能。

适用场景：不同于任务分支，一条开发分支可以用于多个新功能的开发。常用在功能之间依赖性较强的项目中；对变更控制要求不太严格、软件产品相对不太稳定的开发初期或中期，减少分支合并的工作量。

合并或集成策略：按照软件发布计划制定合并的计划，或周期性合并。注意，在合并时间点要确保只合并逻辑上完整的变更。

2.1.5.维护分支：

概念：用于已发布版本的缺陷修复和次要的功能增强；

作用：开发新功能的同时，维护已发布版。能够针对特定的发布版发布补丁版本。隔离未发布版新功能开发对已发布版的影响。

适用场景：项目组经过一段时间的开发工作，已经发布了一个或多个版本。为了保证维护与后续开发互不影响，同时进行，可为每个发布版本创建维护分支。维护分支最终会与新版本开发作集成。

合并或集成策略：维护分支上每发布一个补丁，就要将其变更同步到开发分支。或者维护分支经过测试后，将变更同步到开发分支。确定该版本不再维护后，该分支才可以废弃。

2.1.6.项目分支

概念：按照项目创建的分支。例如，软件开发过程中，从1.0的基础上开发2.0的版本，如果1.0需要继续开发或维护，2.0可以单独创建一个分支。

作用：在同一个仓库中开发不同的项目。

适用场景：在项目的某个版本上开发新版本，并且该新版本与已发布版不会被合并。

合并或集成策略：通常情况下，项目分支之间只进行通用功能或基础代码的缺陷修复的同步。除非项目不再开发或维护，否则项目分支一直存在。

2.1.7.第三方代码分支

概念：为了保存和维护第三方代码而创建的分支。在版本控制系统中同时保存来自供应商的版本和项目组提供给客户的版本。使用该分支跟踪供应商代码的开发

适用场景：项目需要维护和移植第三方的代码。第三方代码可能直接被使用，或者经过简单的定制、重新打包。因项目经常需要与供应商发布的新版本做同步，或复制代码供应商的早期版本。

作用：很容易获知项目对第三方代码修改的内容及变更，所以很清楚需要对供应商的某个发布版做哪些修改；很容易得知供应商的两个版本之间的变更内容

合并或集成策略：当收到供应商的新版本后，把它作为供应商代码分支的新版本，并将代码从该分支合并到项目的开发分支。

3. 常见问题及解决方案

3.1.1.如何降低变更的集成风险？

Context：开发人员完成了变更任务，准备做变更的合并。因为变更所在的多个分支具有高风险、高复杂性，需要保证合并的可靠性和一致性。

Problem：谁来负责合并？谁保证集成的正确性？

Solution：设置集成分支负责人。集成负责人负责将变更同步到集成分支。如果出现冲突，集成负责人组织变更的所有者或代码所有者来解决，并保证合并的正确性。合并成功之后，负责人再次将集成分支的merge到开发分支。对于使用了ClearCase的项目来说，集成流可实现集成分支的功能。SVN的主线也能够实现集成分支的功能。

3.1.2.如何在没有相互影响的情况下进行两个发布版的开

发？

Context：项目组需要在短时间内开发两个主要的发布版。这两个交付的日程表相当具有挑战性。Solution：因为时间不充足，必须避免一切不必要的等待和延迟。在当前的开发分支上创建一个