软件版本控制规范

Date of Issue: 2012/08/06 Version: 1.0

Revision History

1 目的 (1)

2 适用范围 (1)

3 职责 (1)

3.1 开发人员1

3.2 发布人员1

4 工作程序 (1)

4.1 项目开发人员注意事项1

4.2 版本管理策略2

软件版本控制规范

1 目的

规范部门软件产品版本升级流程，清晰管理版本号，加强不同版本软件保存的可靠性。

2 适用范围

适用于开发结束进行测试或投入应用的软件系统的升级或变更管理。

3 职责

3.1开发人员

开发人员负责代码的开发，开发的代码需提交到正确的svn地址。

3.2发布人员

发布人员负责代码的发布，发布的代码需根据release note从svn获得，发布后需向所有相关人员发送成功的邮件，并更新JIRA上的状态。

4 工作程序

4.1项目开发人员注意事项

4.1.1开发人员每天早上至少从svn上update一次代码，下班前需再次update代

码后，将修改的代码commit到svn。

4.1.2开发人员更新或提交代码时如果发现有代码冲突，需立即找代码冲突的相关

人员查找原因，严禁直接强制提交。

精品

4.1.3发布代码到uat和生产机需由专门的发布人员操作，每次发布到uat和生产

机，需在JIRA上登记。

4.1.4发布人员只接收release note，发布人员根据release note从svn拉下代

码并打包，不接收开发人员拷贝的代码文件。

4.1.5发布代码到生产机需根据release note生成check list，由开发人员和发

布人员根据check list检查无误后进行发布，release note和check list

的结果需在svn上留档。

4.1.6发布生产机成功后，发布人员需向所有相关人员发送成功的邮件，并更新

JIRA上的状态。

4.2版本管理策略

4.2.1代码分支的管理

4.2.1.1代码分支管理示意图

参见图4.2.1.1

精品

图4.2.1.1

4.2.1.2代码分支管理策略

在使用版本控制系统时，必须考虑如何设置分支结构。可以通过镜像源代码文件来创建一个分支。然后，可以在不影响源的情况下更改该分支。例如，如图4.2.1.2.1的分支结构所示，MAIN 分支包含已通过集成测试的已完成功能，而 DEVELOPMENT 分支包含团队正在构建的代码。当 DEVELOPMENT 分支中的新功能完成并可通过集成测试时，可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支中。此过程称为“反向集成”。反之，如果将代码从 MAIN 分支合并到 DEVELOPMENT 分支中，则此过程称为“正向集成”。

精品

图4.2.1.2.1

分支和合并需要遵循下列原则：

1. 每个分支都必须具有一个定义的策略，此策略与如何将代码集成到相应分支中有关。例如，在图4.

2.1.2.1的分支结构中，可以指定一个团队成员来拥有和管理 MAIN 分支。该成员负责执行初始分支操作、将更改从 DEVELOPMENT 分支反向集成到 MAIN 分支，以及将更改从 MAIN 分支正向集成到 DEVELOPMENT 分支。当 MAIN 分支也从其他分支集成更改时，正向集成非常重要。

2. MAIN 分支必须包含已通过集成测试的代码，以便始终准备进行发布。

3. 由于团队成员会定期签入更改，因此 DEVELOPMENT（或工作）分支将不断演变。

4. 标签(tag)是分支中的文件在某个特定时间的快照。

反向集成和正向集成的频率：

反向集成和正向集成应至少在用户情景完成时进行。虽然每个团队对于完成的定义可能不同，但完成用户情景通常意味着完成了功能和对应的单元测试。只能在单元测试验证DEVELOPMENT 分支的稳定性后反向集成到 MAIN 分支中。如图4.2.1.2.2所示。

精品

图4.2.1.2.2

如果具有多个工作（即 DEVELOPMENT）分支，则当任意分支集成到 MAIN 分支时应立刻正向集成到所有工作分支。因为 MAIN 分支保持稳定，所以正向集成是安全的。工作分支中可能会发生某些冲突或失败，这是因为无法保障工作分支是稳定的。

应尽快解决所有冲突，这非常重要。

4.2.1.3添加分支的时机

以下情况下应创建分支：

•在必须按与现有分支不同的时间表/周期发布代码时。

•在代码需要不同的分支策略时。如果创建具有新策略的新分支，则可以为项目增添策略价值。

•在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。

不应对每个用户情景创建分支，因为这会产生较高的集成成本。虽然通过可方便地进行分支，但在分支很多时，管理分支的开销可能会很大。

4.2.1.4从版本控制的角度，关于发布的管理

精品

团队应能在任意冲刺 (sprint) 末尾发布代码。可以标记(tag)一个分支以在某个特定时间点为代码拍摄快照。如图4.2.1.4.1所示，可以为发布标记 MAIN 分支。这样，就可以将分支返回到此时间点时的状态。

注意只有已反向集成到MAIN 分支的代码才能被发布。

图4.2.1.4.1

在为发布创建分支时，应从 MAIN 分支（该分支最稳定）创建分支。如果从工作分支对发布进行分支，则会导致集成问题，因为无法保证工作分支的稳定性。

4.2.1.5分支或标签(tag)的命名

版本号Smartphone_20110905

代号a b

代号说明

a项目代号，首字母大写，推荐使用驼峰式命名。

b创建日期，4位年，2位月，2位日，位数不够补0。

例：

Smartphone项目在2011年9月5日创建了一个分支，则分支命名为Smartphone_20110905

精品