代码版本管理规范.pdf

XXXXXXXX 代码版本管理规范 历史版本 本号 主要作者 修改记录 完成日期 XXX 新建文档 2015/12/16 目录 历史版本 错误 !未定义书签。 1 引言 错误 !未定义书签。 目的. 错误 !未定义书签。 管理工具 . 错误 !未定义书签。 2 现状概述 错误 !未定义书签。 3 现状分析 错误 !未定义书签。 现状详述 . 错误 !未定义书签。 目标细化 . 错误 !未定义书签。 SVN版本管理 错误 !未定义书签。 概述 错误 !未定义书签。 使用对比 错误 !未定义书签。 4 完整的实施方案 错误 !未定义书签。 开发阶段 . 错误 !未定义书签。 预发布测试阶段 . 错误 !未定义书签。 1 引言 1.1 目的 为了规范和制度化公司的软件版本管理制度， 并保障项目开发资料的完整性和安全性， 同时 明确开发源代码的控制管理流程，特此制定此规范。 1.2 管理工具 沿用 SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。 2 现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档， 导致所有正在开发的需求和项目都在同一个目录里面进行修改， 造成每次发版的代码都有可 能包含了本次发版以外的内容。 这样会造成如下两点影响： 会有不稳定的因素存在， 比如：测试只会对当前需要发版的内容进行测试， 但是代码库 中同时存在多个版本和项目的代码， 对于本次发版无涉及的代码没有进过测试就部署到 了服务器上，影响运行的稳定性。 一旦出现点问题不好定位， 比如： 出现问题后通常会优先排查发版涉及的内容， 但是部 分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3 现状分析 3.1 现状详述 当前代码版本管理现状如下： 1. 所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2. 提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3. 测试出 bug 以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代 码就可能包含了他人对其他功能 / 项目的修改，而测试又只会针对此 bug 再做测试。这 就导致了除了此 bug 之外的修改可能会没有测试过就直接发布到了服务器上， 引起预发 布环境不稳定并增加预发布 bug 数量。 总体来说，当前工作流程是：预发布出 bug，研发修改，再提交测试，然后预发布测试 通过的代码。整个流程也较为复杂消耗了大量人力，从而间接的增大了研发成本。