代码版本管理规范_v1.1.docx

XXXXXXXX 代码版本管理规范 历史版本 版本号主要作者修改记录完成日期0.1XXX新建文档2015/12/160.20.30.4  目录  TOC \o 1-3 \h \z \u  HYPERLINK \l _Toc438038110 历史版本  PAGEREF _Toc438038110 \h 2  HYPERLINK \l _Toc438038111 1 引言  PAGEREF _Toc438038111 \h 4  HYPERLINK \l _Toc438038112 1.1 目的  PAGEREF _Toc438038112 \h 4  HYPERLINK \l _Toc438038113 1.2 管理工具  PAGEREF _Toc438038113 \h 4  HYPERLINK \l _Toc438038114 2 现状概述  PAGEREF _Toc438038114 \h 5  HYPERLINK \l _Toc438038115 3 现状分析  PAGEREF _Toc438038115 \h 5  HYPERLINK \l _Toc438038116 3.1 现状详述  PAGEREF _Toc438038116 \h 5  HYPERLINK \l _Toc438038117 3.2 目标细化  PAGEREF _Toc438038117 \h 6  HYPERLINK \l _Toc438038118 3.3 SVN版本管理  PAGEREF _Toc438038118 \h 6  HYPERLINK \l _Toc438038119 3.3.1 概述  PAGEREF _Toc438038119 \h 6  HYPERLINK \l _Toc438038120 3.3.2 使用对比  PAGEREF _Toc438038120 \h 7  HYPERLINK \l _Toc438038121 4 完整的实施方案  PAGEREF _Toc438038121 \h 9  HYPERLINK \l _Toc438038122 4.1 开发阶段  PAGEREF _Toc438038122 \h 9  HYPERLINK \l _Toc438038123 4.2 预发布测试阶段  PAGEREF _Toc438038123 \h 9   引言 目的 为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 管理工具 沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。  现状概述 目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。 这样会造成如下两点影响： 会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。 因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 现状分析 现状详述 当前代码版本管理现状如下： 所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。 总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试通过的代码。整个流程也较为复杂消耗了大量人力，从而间接的增大了研发成本。(参照下图) 开发库 测试服 开发库 测试服 再提交 预发布 发现橙色bug 提交 开发库 他人修改的代码 修复Bug 以上描述的过程还可能出现在正式环境上，导致更严重的后果。 目标细化 结合第一章节提及的本文目标、SVN工具的能力以及之前工作中遇到的具体问题，将本规范的撰写目标具体细化为： 提交到测试服务器的代码只能包含本次需要测试的内容。 发