版本控制分支_版本控制分支策略

版本控制分支

大约两年前，我们在一家大型电信组织上启动了一个新项目（与SOA / BPM基础结构有关）。 自去年夏天以来，该项目进展顺利，并已投入生产。 我们开发了越来越多的模块，一切进展顺利。 现在是时候将知识转移给客户的开发人员了。 我们必须教给他们的主要内容是命名约定，源代码，体系结构和管理任务。 因为我们将在同一个团队中待几个月，所以首先我们必须向他们解释我们的版本控制分支策略。

因此，在这篇文章中，我将解释我们在版本控制分支策略上的方法。 我们在花费大量时间进行对话和阅读后定义的一种方法。

事实：

• 我们有许多相互关联的个人/自治应用程序。
• 每个应用程序至少依赖于另一个应用程序（基于WSDL）。
• 我们没有质量保证经理，也没有发布经理，因此我们从事与设计，开发，发布管理和管理任务相关的所有工作。
• 我们定义了3种测试类型（与发布相关）：
  • 单元测试：可以由我们（开发人员）完成的测试，而无需与外部系统（例如CRM，Billing等）进行通信。

规则：

1. 我们遵循不稳定的分支策略。 这意味着干线包含最新的代码，而不管其必须如何稳定。
2. 分支仅用于候选发行版，发行版，错误修正和实验代码。
3. 为标签使用一致的标签命名方案：
4. 1. 分支标签将始终以“ BT_”开头
   2. 发行候选前缀为“ RC_”
   3. 发布前缀为“ R_”
   4. 错误修正前缀为“ BF_”
   5. 实验代码前缀为“ EC_”
   6. 开发人员代码以“ DEV_”开头
   7. 分支名称始终以“ BR_”开头
5. 标记总是在主干上创建：
   1. 创建分支之前：<branchName> _BASE（例如RC_2_0_ApplicationName_BASE ）
   2. 在将分支合并到中继之前：<branchTabName> _PMB（PMB：合并前分支）
   3. 合并分支到主干后：<branchTagName> _AMB（AMB：合并后分支）（例如RC_2_0_ApplicationName_AMB ）
6. 工作完成后，请务必在分支中执行标签，后缀为“ –counter”，并始终增加计数器（例如BT_RC_2_0–1_ApplicationName ）。
7. 经常合并； 中继更改越少，合并就越容易。
8. 为每个应用程序创建一个Wiki页面，并为每个单独的标签和分支编写详细信息。
9. 在您的错误跟踪系统上将标签记录在相关的问题/错误中。

以上规则/步骤仅适用于一个应用程序，但对所有应用程序均相同。

好的，是时候使用简单的发布管理示例了。 在大多数情况下，图像胜于数千个单词。 这并不总是正确的，试图找到一个图像明智的解释。 我相信你不会。 已经写了很多书，但是我们仍然无法理解/定义明智的方法 。 为人类感到难过……。 让我们来看一些更简单的事情，例如发布管理。 因此，请检查以下图像：

应用程序PName的发布候选方案：

1. 开发是在TRUNC上完成的，所有开发人员都在那里工作。 应用程序处于稳定版本1_9。 经过大量更改后，要发布2_0。 使用下划线代替点，以符合大多数版本控制软件变体（CVS不接受标记中的点）
2. 当开发人员完成单元测试和他可以完成的许多集成测试时，然后确定该应用程序已准备好进行集成和验收测试，因此他在中继上创建了一个名称为'RC_2_0_PName_BASE'的标签。 这是TRUNK上的候选发布时间戳，因为标签是时间戳。
3. 使用名称“ BR_RC2_0_PName”分支发布了候选版本2_0。
4. 在集成测试期间，出现了问题。 它固定在分支上，然后标记为BT_RC2_0–1_PName。
5. 开发人员认为最好将更改合并回TRUNC，而其他开发团队将继续朝RC3_0努力。 因此，必须完成两件事：
6. 1. AppName应用程序的提交已暂停（使用响亮的提示，例如“去喝咖啡，我必须合并到行李箱”）。
   2. 他用RC2_0–1_PName_PMB标记了TRUNK。
7. 开发人员将分支合并到TRUNC。
8. 开发人员进行必要的提交（如果有），以在TRUNC上具有有效的应用程序，并在TRUNC上创建名为RC2_0–1_PName_AMB的新标签。 开发人员宣布“恢复工作”，并取消暂停PName应用程序上的提交。
9. 在验收测试期间，会引发另一个问题。 代码需要进行一些修改，在几次提交之后，问题就可以解决并提交到分支上。 然后将分支标记为BT_RC2_0–2_PName。 这里没有合并到主干（开发人员在这里决定，因为他是我们的案例中的发布经理）
10. 在验收测试期间，会引发另一个问题。 代码需要进行一些修改，在几次提交之后，问题就可以解决并提交到分支上。 然后将分支标记为BT_RC2_0–3_PName。
11. 验收测试在未附加修改的代码的情况下完成。 现在释放“ 2_0？ 准备好了。 开发人员在分支上创建标签BT_R2_0_PName，该标签与BT_RC2_0–3_PName完全相同。
12. 现在，开发人员必须将代码合并到TRUNK。 首先暂停干线上的提交，然后创建一个名为R2_0_PName_PMB的标签。
13. 开发人员将更改合并到主干。
14. 然后执行其他必需的提交，并创建另一个名为R2_0_PName_AMB的标签，然后在TRUNK上取消暂停提交。
15. 当应用程序（版本2_0）在生产中运行时，提出了另一个问题，需要快速修复 。 问题已在分支上解决，并在分支上创建了名称为BT_RC2_0_1_PName的标记。
16. 此外，该快速修复程序还标记为发布，标签名称为BT_R2_0_1_PName。
17. 开发人员必须（在大多数情况下）将更改合并回TRUNC，而其余的开发则继续朝RC3_0工作。 因此，他暂停了对应用程序的提交，并使用R2_0_1_PName_PMB标记了TRUNK。
18. 开发人员将更改从分支合并到主干。
19. 开发人员进行必要的提交才能在TRUNC上具有有效的应用程序，并在TRUNC上创建一个名为R2_0_1_PName_AMB的新标签。
20. 在TRUNK上的开发仍在朝RC3_0进行，工作永无止境…

以上规则/步骤仅涉及一个应用程序，但对于所有应用程序都是相同的。

请再次阅读本系列的第一篇文章以了解规则 。 我知道您需要图片上的说明，因此请提出。 一些重要的解释：

• 分支标签将始终以“ BT_”开头
• 发行候选前缀为“ RC_”
• 发布前缀为“ R_”
• 版本号用下划线分隔（例如2_0）
• 不是发行版但与候选发行版相关的标签使用2个破折号“ –”（例如2_0–1）

使用此过程，我们可以返回到所需的任何PName版本（使用分支标签），并通过快速修复继续分支，甚至创建分支的新分支。

我知道有更好，更优雅的程序，但这只是我们遵循的程序，适用于我们的小型开发团队。 它很简单，没有任何其他工具，但是需要开发人员之间进行强有力的沟通，问题跟踪程序（我们使用mantisbt ）需要开发人员始终遵守规则。 另外，您很多人都需要一个Wiki（我们使用MediaWiki ）来记录每个应用程序的所有标签。 发行说明记录在问题跟踪器中。

如果没有规则和版本管理程序，那么在发布几个产品后，即使是很小的应用程序也可能非常复杂。 始终定义规则，并确保所有开发人员都可接受。 如果定义的过程中存在泄漏，则开发人员将发现并确定将其应用。 现在，开发人员是产品的用户（产品=发布管理程序），并且用户始终是不可预测的 。

别忘了分享！

参考： 版本控制分支策略1/2 ，   我们的JCG合作伙伴 Adrianos Dadis在Java，集成和源博客的优点中提出了 版本控制分支策略2/2 。

翻译自: https://www.javacodegeeks.com/2012/09/version-control-branching-strategies.html

版本控制分支