软件版本控制规范讲述.docx

Revision History Date Version Description Author 2011-08-06 draft Efun 2011-08-20 draft 调整了文档的结构，增加了版本控制相关的内容 Efun  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.2 代码分支管理策略 在使用版本控制系统时，必须考虑如何设置分支结构。可以通过镜像源代码文件来创建一个分支。然后，可以在不影响源的情况下更改该分支。例如，如图4.2.1.2.1的分支结构所示，MAIN 分支包含已通过集成测试的已完成功能，而 DEVELOPMENT 分支包含团队正在构建的代码。当 DEVELOPMENT 分支中的新功能完成并可通过集成测试时，可以将代码从 DEVELOPMENT 分支提升到 MAIN 分支中。此过程称为“反向集成”。反之，如果将代码从 MAIN 分支合并到 DEVELOPMENT 分支中，则此过程称为“正向集成”。 分支和合并需要遵循下列原则： 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所示。 如果具有多个工作（即 DEVELOPMENT）分支，则当任意分支集成到 MAIN 分支时应立刻正向集成到所有工作分支。因为 MAIN 分支保持稳定，所以正向集成是安全的。工作分支中可能会发生某些冲突或失败，这是因为无法保障工作分支是稳定的。 应尽快解决所有冲突，这非常重要。 4.2.1.3 添加分支的时机 以下情况下应创建分支： ? 在必须按与现有分支不同的时间表/周期发布代码时。 ? 在代码需要不同的分支策略时。如果创建具有新策略的新分支，则可以为项目增添策略价值。 ? 在向客户发布功能且团队打算进行不影响计划的发布周期的更改时。 不应对每个用户情景创建分支，因为这会产生较高的集成成本。虽然通过 可方便地进行分支，但在分支很多时，管理分支的开销可能会