代码版本管理规范_v11

1、xxxxxxxx代码版本管理规范历史版本版本号 主要作者修改记录完成日期0.1XXX新建文档2015/12/160.20.30.4目录历史版本21 引言41.1 目的41.2 管理工具42 现状概述53 现状分析53.1 现状详述53.2 目标细化63.3 SVN版本管理 63.3.1 概述63.3.2 使用对比74 完整的实施方案94.1 开发阶段94.2 预发布测试阶段91引言1.1 目的为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，明确开发源 同时 代码的控制管理流程，特此制定此规范。1.2 管理工具沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资

2、料归档。2现状概述目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。这样会造成如下两点影响：会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。3现状分析3

3、.1现状详述当前代码版本管理现状如下：1 .所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。2 .提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。3 .测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。bug数量。这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试通过的代码。整个流程也较为复杂消耗了大量人力，从而间接的增大

4、了研发成本。（参照提交 发现橙色bugM 开发库测试服4 .以上描述的过程还可能出现在正式环境上，导致更严重的后果。5 .2目标细化结合第一章节提及的本文目标、SVN工具的能力以及之前工作中遇到的具体问题，将本规范的撰写目标具体细化为：1 .提交到测试服务器的代码只能包含本次需要测试的内容。2 .发布到预发布环境的代码只能包含这次需要测试的内容。3 .发布到正式环境的代码只能包含本次发版的内容。3.3 SVN版本管理SVN的版3.3.1 概述为了达成上述我们设定的版本管理目标，在指定具体的策略之前，我们需要理解本管理思路，这里简单将其阐述如下：首先, SVN(Subversio n)有一个很标

5、准的目录结构，如下 project+- trunk+ bran ches+- tags (此目录为只读)这个标准的目录结构在大多数的开源项目中都能看到，这套标准目录结构为软件开发提供了一种非常好的宏观的版本库管理机制，特别是在产品类项目管理中。其中，trunk目录为主开发目录， branches目录为分支开发目录，tags目录为存档目录，也就是基线库。其各自含义描述如下：Trunk中文翻译为“主干”，在项目运作过程中，日常的开发和管理资料都在此目录中进行维护和更新。Bran ches中文意思为“分支”，在项目运作过程中，用于存放阶段性的成果或者版本，这些阶段性的成果或者版本必须是可维护的。同时

6、，这里的开发成果物必须要保持每天一到两次把主干上的内容合并过来。tags中文意思“标签”，此目录对一些阶段性的成果进行存档。此目录为只读目录，不允许进行修改。332使用对比以下假设一个开发场景，并设想当前管理机制和SVN管理思路下的不同流程和结果，以便更好的理解SVN管理思路和带来的收益。场景描述：设备管理模块，其vl.O已经上线，正在做V2.0的开发。在这时，研发在开发库中正在做V2.0的开发，同时备份有V1.0的代码，现在有一个紧急需求，需要在V2.0发版之前就应用到正式环境中去。3.3.2.1现有的发布流程1 .在当前开发库（V2.0 ）的代码上直接修改实现紧急需求。2 .开发完成后，将

7、本紧急需求连同V2.0的半成品代码（但编译能通过）一起打包提交到测试服务器。3 .测试只针对此紧急需求进行测试（V2.0的内容不测试），并测试通过。4 .发预发布环境，同时测试（过程同上）。5 .发到正式服务器。6 .322 SVN的发布流程1 . 2.0开始开发，trunk目录下此时的代码内容为V2.0的开发版（半成品未完成）2 .基于V1.0的tag新建此紧急需求的开发分支（branchVI. 1 ）此时的目录结构为+tru nk/ (deV 2.0 )+bra nches/+dev 1.1 (copy from tag/release 1.0)+tags/+release 1.0 (co

8、py from trunk)3.在 v1.1 branch目录中进行紧急需求开发，在trunk目录中进行版本V2.0开发4 .在v1.1 branch开发完成后，基于v1.1的branch做现有的发布流程。这时在v1.1的branch版本里只涉及了本次要发版的紧急需求，不含有其他修改，很好的规避了现有流程中的弊端。5 .根据需要选择性的把V1.1这个分支merge回trunk （是否执行和具体执行时间需要根据具体需求分析）这是一种标准的开发模式，在很多公司中都有采用，此种模式下trunk永远是开发的主要目录。4完整的实施方案分为开发阶段和测试阶段来分别阐述此方案：4.1开发阶段1 .每一次正式

9、版本发布后，存档形成一个版本基线，例如v1.0，v1.3，v1.3.3。2 .拿到新需求（可以是多个）后，开发人员估计在下一次发版（V2.0 ）时能否开发完成。确定能开发完成随V2.0 一起发版的则直接在主线上开发。3 .若不能确定在下一次发版时能一起发版的，或者修改很大的的情况，就需要新建一个分支，然后在这个 分支上面开发。需要注意的一点是为了保障发版前合并到主线尽量少产生冲突，需要至少每天把主线上 的代码合并到自己开发的分支中来。4 .紧急发版（如bug修改）情况下，需要在下次发版前紧急再发一个版本的情况，就需要基于最新的基 线新建一个分支，然后在这个分支上面进行开发，测试，发版。完成后再将其合并到主线上。4.2预发布测试阶段预发布阶段的情况会稍微特殊一些，流程如下：1 .在预发布的时候先在Tag中做一个发布版本的同步快照2 .然后发布到预发布环境进行测试3 .若发布测试通过要正式发版的时候，如果在发布版本上有了修改（如bug修复），需要再评估修改带来的影往预发布环境发布的时候，就需要先和Tag中的快照进行版本比对