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