配置管理分支策略指引

1、分支策略指南1. 分支的重要性在日常的软件开发工作中，项目经常会遇到下面需求：1、 开发新版本的同时，希望能够修改项目早期版本中的某个bug,并在修复后立即发布早 期版本的补丁；2、 其它的小组成员为了开发某个功能占有了你希望处理的文件，因为该功能开发时间较长， 你希望不要等待他释放后再开发自己的功能，而是同时进行，以便节省开发时间；3、 你所做的工作涉及到许多文件，你希望能够避免经常打乱别人的工作，其他人的工作也不会对你产生影响，而且你可以将所有的工作测试完后再将它们集成到你的项目中。以上的需求都可以采用并行开发的模式来实现。并行开发能够提升团队协作能力，提高开发效率。但是，并行开发为项目带

2、来好处的同时，也增加了管理的难度， 需要一定的过程和方法的支持。软件分支是软件版本控制、软件构建管理和版本发布管理的重要组成部分，是支持软件并行开发的常用机制。运用分支使得并行开发新的系统、同步更改多个并行版本的错误、同时集成和发布多个版本成为可能。许多版本管理工具， 如ClearCase、SVN等，都支持分支。工具为我们解决了大部分并行开发的问题，我们要做的就是根据项目的具体情况，制定适合的分支策略并采用工具来实现。2. 常见的分支类型及适用场景软件开发团队经常使用的有几种分支：2.1.1.组件分支概念：按照开发组所负责的组件或模块来分，每个小组一个分支；作用：隔离模块或组件之间的相互影响。

3、模块或组件可单独发布， 有独立的发布周期或计划。适用场景：组件或模块需要单独发布，发布周期不同。合并或集成策略： 每当某个组件发布了新基线或版本，就要进行一次集成。 为了保证“尽早并经常集成”，可以通过发布计划等，提高组件发布基线或版本的频率。合并后，分支继续 使用。2.1.2.任务分支概念：每个开发任务一个分支。例如设立新功能A开发分支，新功能 B开发分支等；作用：隔离开发周期不同的多个功能，避免相互之间的影响， 使得并行开发多个功能成为可能，节省开发时间。每个功能可独立合并、测试，降低了集成的难度与风险。适用场景：对软件质量要求较高，希望新功能可独立测试；多个功能发布时间点不同，希望 能够

4、同时开发，节省开发时间；一个任务所要修改的文件， 通常与其他任务要修改的文件重 叠。合并或集成策略：一旦完成，该分支就应该被合并到其父分支中，之后该分支就会被废弃掉。2.1.3. 活动分支概念：一个变更识别为一个活动，为每个活动创建一个分支。作用：使得软件能够快速测试、发布针对某个变更的补丁。容易控制软件补丁的质量。适用场景：每个变更一个分支， 管理成本较高，因此常用在需要严格控制变更的软件维护阶 段，或变更较少的某个开发、测试阶段。才2.1.4. 开发分支概念：未发布的版本使用的分支，只进行“新"的开发；作用：开发某个发布版的多个新功能。适用场景：不同于任务分支，一条开发分支可以用

5、于多个新功能的开发。常用在功能之间依赖性较强的项目中；对变更控制要求不太严格、软件产品相对不太稳定的开发初期或中期， 减少分支合并的工作量。合并或集成策略：按照软件发布计划制定合并的计划，或周期性合并。注意，在合并时间点要确保只合并逻辑上完整的变更。2.1.5. 维护分支：概念：用于已发布版本的缺陷修复和次要的功能增强；作用：开发新功能的同时，维护已发布版。能够针对特定的发布版发布补丁版本。隔离未发布版新功能开发对已发布版的影响。适用场景：项目组经过一段时间的开发工作，已经发布了一个或多个版本。为了保证维护与后续开发互不影响，同时进行，可为每个发布版本创建维护分支。维护分支最终会与新版本开发作

6、集成。合并或集成策略：维护分支上每发布一个补丁，就要将其变更同步到开发分支。或者维护分支经过测试后，将变更同步到开发分支。确定该版本不再维护后，该分支才可以废弃。2.1.6.项目分支概念：按照项目创建的分支。例如，软件开发过程中，从 1.0的基础上开发2.0的版本，如 果1.0需要继续开发或维护，2.0可以单独创建一个分支。作用：在同一个仓库中开发不同的项目。适用场景：在项目的某个版本上开发新版本，并且该新版本与已发布版不会被合并。7.第三方代码分支2.1.7.第三方代码分支合并或集成策略：通常情况下，项目分支之间只进行通用功能或基础代码的缺陷修复的同步。 除非项目不再开发或维护，否则项目分支

7、一直存在。概念：为了保存和维护第三方代码而创建的分支。在版本控制系统中同时保存来自供应商的版本和项目组提供给客户的版本。使用该分支跟踪供应商代码的开发适用场景：项目需要维护和移植第三方的代码。第三方代码可能直接被使用， 或者经过简单的定制、重新打包。因项目经常需要与供应商发布的新版本做同步，或复制代码供应商的早期版本。作用：很容易获知项目对第三方代码修改的内容及变更，所以很清楚需要对供应商的某个发布版做哪些修改；很容易得知供应商的两个版本之间的变更内容合并或集成策略：当收到供应商的新版本后，把它作为供应商代码分支的新版本，并将代码从该分支合并到项目的开发分支。ohteined from ven

8、dorohteined from vendorobtained from vendor3. 常见问题及解决方案3.1.1. 如何降低变更的集成风险？Context:开发人员完成了变更任务，准备做变更的合并。因为变更所在的多个分支具有高风险、高复杂性，需要保证合并的可靠性和一致性。Problem :谁来负责合并？谁保证集成的正确性？Solution：设置集成分支负责人。集成负责人负责将变更同步到集成分支。如果出现冲突，集成 负责人组织变更的所有者或代码所有者来解决，并保证合并的正确性。合并成功之后，负责人再次将集成分支的 merge到开发分支。对于使用了ClearCase的项目来说，集成流可实现

9、集成分支AWCKjngjine的功能。SVN的主线也能够实现集成分支的功能。stabilize3.1.2. 如何在没有相互影响的情况下进行两个发布版的开发？Context:项目组需要在短时间内开发两个主要的发布版。这两个交付的日程表相当具有挑战性。Solution：因为时间不充足，必须避免一切不必要的等待和延退。在当前的开发分支上创建一个新的发布分支，用于下一个增量开发。也可以将当前开发分支合并到主线后，在主线上创建新的发布分支。这样两个增量开发可以在不同的分支上进行。在相对较早发布的开发分支上，每隔一段时间需要将其特性和变更合并到相对较晚发布的分支中。确保变更的合并在适当的、稳定的基线级别进

10、行、尽早并经常进行。新的发布分支，通常在开始为这个发布做开发时创建。当然，如 果你不需要隔离两个发布的全部工作，也可以在需要的时候再创建分支。3.1.3. 如何在进行下一个版本开发的同时，及时响应上一个版本的缺陷和功能增强请求，并对当前发布版本的开发不产生任何影响？Context :项目的已经完成一个发布版，准备进行下一个发布版的开发。Solution:不要在一个分支上同时进行新版本的开发和已发布版本的维护，应该将两者分开 放在不同的分支上进行。已发布版本的缺陷修复和功能增强在维护分支上进行。下一个发布版本的开发在独立的开发分支进行。确保维护分支上的变更按一定的频率合并到开发分支。方法一：如下

11、图，创建两个分支，一个是开发分支，一个是维护分支。方法二：更常见的做法是创建一个维护分支，下一个版本的开发仍然在原代码线 上进行。如下图：3.1.4. 如何将分支的数虽控制在一个可管理的范围，使项目的版本树不会越来越宽，越来越深？Context:在开发和维护的生命周期内，因为多种原因创建了很多分支。例如：开发分支、维 护分支、发布分支等。随着时间的推移，出现大量的级联分支，使项目的版本树越来越宽。如下图：Solution：在主线上，或贴近主线的位置保留一个“home branch ”。需要创建一个主要发布版本分支的时候，不要在当前的分支上创建，而是先将当前分支合并到"home bra

12、nch”，然后在"home branch”上创建新的分支。这条主线上不进行任何开发工作，所有的变更都来自 于其他分支。唯一能够在主线做的变更是，为了保证在该主线上的集成和构建的一致性所做 的变更。3.1.5. 如何组织远程的开发任务，使得其不会对本地开发主线产生不利影响，并且不会对远程开发者的工作产生不必要的延时。Context:项目组与地理上相距较远的开发者合作开发。远程开发者可能是与项目组签订分包协议的分包商。本地和远程所作的变更任务最终都会被集成到同一开发线。但是你希望远程修改的代码在合并到本地开发线之前，经过必要的验证。Solution:在本地使用主开发线，为每个远程站点建立

13、远程开发分支。远程开发人员在远程开发分支上工作，本地定期选择合适的时机，验证远程开发分支中的变更，并将变更合并到本地的主开发线。远程站点定义合适的周期，与本地开发主线做同步另外一种可行的方案是，本地也创建一个开发分支，本地和远程都将变更合并到本地另外一 条开发主线。这样，本地和远程定期的与本地开发主线做同步。3.1.6. 开发人员如何知道他的代码应该保存在哪条分支中，什么时候保存？Context:在开发软件系统的过程中，项目组使用了多种分支。开发人员很难弄清代码应该 保存在那条分支，什么时候保存等问题。Solution:首先，分支的名称要有意义，易理解。其次，要制定分支的策略，策略中除了清晰简

14、明的描述分支的目的外，还可以选择性包含下面内容：该分支上要做哪一类的工作。例如：开发、维护、某个特定的发布版、某个功能 或子系统。该分支上的元素，应该在什么时候、如何checkout/checkin、创建子分支和合并？该分支对于不同组和角色的存取控制权限 该分支用于接收变更，还是将变更传递出去？ 该分支的使用期限和退休条件。预期的活动负载及集成频率制定分支的策略之后，应该将其放在大家容易获取的位置。有些配置管理工具提供了分支命名和填写分支注释的功能，我们可以借用此功能保存分支策略。3.1.7. 如何判断修改活动是否应该在该分支执行？由谁来决定并保证修改的完整性和一致性？Context:在众多的

15、分支中，某个开发人员使用至少一条分支。分支策略中定义了 checkin/checkout的策略。某些人想对该分支做一些修改，但是此分支策略中并没有描述相 关内容，或者描述模糊Solution：为每个分支分配一个所有者，该所有的职责包括：澄清分支的策略等。决定是保留还是丢弃违反分支策略checkin的代码。协助或执行向该分支中合并变更。决定该分支什么时候应该被冻结和解冻，什么时间结束并合并到主线。设置分支的访问控制权限。分支的所有者有权限控制的职责。例如下面的权限设置：只有分支的所有者才能checkin文件；其他人在得到了分支所有者的授权才能checkin；在checkin之后立即通知分支所有者；通常存取次数多的分支，需要更严格的权限控制策略。4. 分支使用的几点原则及注意事项使用有意义的分支名称：有意义的分支名称方便管理，便于开发人员选择正确 的分支存取代码。使用多分支而不是冻结代码：例如使用主线集成开发分支的变更，而不是在主线上开发。否则版本发布时需要冻结主线代码进行验证和修复，浪费开发时间。尽早并经常集成：分支中新的变更一旦准备好，就应该进行变更合并。为不兼容的开发创建分支：使用分支作不兼容开发，能够很好的避免相互影响， 提高质量和开发速度。创建适当数量的分支： 不要期望分支可以解决项目的所有问