版本控制与分支管理策略

在一家大型电信公司，我们两年前启动了一个与SOA/BPM基础设施相关的项目。自去年夏天以来，项目进展顺利，并已成功投入生产。随着模块数量的增加，现在需要将知识转移给客户的开发人员，特别是关于命名约定、源代码、体系结构和管理任务。

为了帮助客户开发人员理解我们的工作方式，首先需要向他们解释我们的版本控制分支策略。这一策略是在经过深入讨论和研究后制定的。

### 项目背景
- 我们有许多相互关联的应用程序。
- 每个应用程序至少依赖于其他应用程序（基于WSDL）。
- 团队没有专门的质量保证经理或发布经理，因此我们负责设计、开发、发布管理和日常管理任务。
- 定义了三种主要的测试类型：单元测试、集成测试和验收测试。

### 分支策略规则
1. **主线不稳定**：主线包含最新的代码，但不一定稳定。
2. **分支用途**：分支仅用于发布候选版本、正式发布、错误修复和实验代码。
3. **标签命名规范**：
- 分支标签以“BT_”开头。
- 发布候选前缀为“RC_”。
- 正式发布前缀为“R_”。
- 错误修复前缀为“BF_”。
- 实验代码前缀为“EC_”。
- 开发人员代码以“DEV_”开头。
- 分支名称始终以“BR_”开头。
4. **标签创建**：
- 创建分支之前，在主干上创建一个带有“_BASE”的标签。
- 在合并分支到主干之前，创建带有“_PMB”的标签。
- 合并后，在主干上创建带有“_AMB”的标签。
5. **计数器使用**：完成工作后，在分支中添加带有“-counter”的标签，并递增计数器。
6. **频繁合并**：尽量频繁地将更改合并回主干，以减少冲突。
7. **文档记录**：为每个应用程序创建Wiki页面，并详细记录每个标签和分支。
8. **问题跟踪**：将标签记录在问题跟踪系统中。

### 示例发布管理流程
假设我们要发布版本2.0的应用程序PName。
1. 所有开发都在TRUNC上进行，当前稳定版本为1.9。经过大量更改后，准备发布2.0。
2. 开发人员完成单元测试和部分集成测试后，创建名为“RC_2_0_PName_BASE”的标签。
3. 使用名称“BR_RC2_0_PName”创建发布候选分支。
4. 集成测试期间发现问题，修复后标记为“BT_RC2_0–1_PName”。
5. 将修复合并回TRUNC，并暂停其他开发团队的提交。
6. 创建名为“RC2_0–1_PName_PMB”的标签，然后合并到TRUNC。
7. 提交必要的更改，并创建名为“RC2_0–1_PName_AMB”的标签，取消提交暂停。
8. 验收测试期间再次发现问题，修复后标记为“BT_RC2_0–2_PName”。
9. 继续修复并标记为“BT_RC2_0–3_PName”，最终验收测试通过。
10. 创建名为“BT_R2_0_PName”的标签，表示版本2.0准备好发布。
11. 将代码合并回TRUNC，创建名为“R2_0_PName_PMB”的标签，再合并到主干。
12. 创建名为“R2_0_PName_AMB”的标签，取消提交暂停。
13. 生产环境中出现问题时，快速修复并标记为“BT_RC2_0_1_PName”，同时创建正式发布标签“BT_R2_0_1_PName”。
14. 将快速修复合并回TRUNC，并继续朝下一个版本RC3_0努力。

通过遵循这些规则，我们可以轻松返回到任何版本，并进行必要的修复和改进。虽然这个过程可能不是最优雅的，但它适用于我们小型开发团队的需求。