当前位置：文档库 › 版本管理规范

版本管理规范

版本管理与控制规范

1.目的

按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到任何版本。

2.角色与职责

所有项目成员都必须遵照版本控制规则程操作。

3.版本状态变迁规则

版本状态变迁要遵守一定的规则，内部先生成一个内部版本，提交测试审批，通过了则由CMO进行版本归档，不通过则为无效版本，不进行归档。

4.版本号规则

每一个归档版本都有两个版本号：内部版本号和外部版本号。

内部版本号使用VBP规则，V是指外部版本号，B是指内部版本号，P是指补丁版本号（可选）。

5.版本控制的主要步骤

5.1创建版本

为例修改BUG，或者引入新特性，则会创建一个新版本，此时的版本一般是内部版本。

5.2测试审批

内部版本经过测试，测试人员提供完善的测试报告，然后由项目经理和测试人员共同审批。

5.3版本归入版本库

测试和审批通过之后，由CMO（配置管理员）归入版本库，除了源文件，同时归档的有测试报告、版本配套表、升级指导书等相关文档。

版本管理规范

版本管理规范 ■标准化文件发布号：（9456?EUATWK?MWUB?WUNN?INNUL-DDQTY-KII

版本管理规范一?版本管理办法 1.1目的按照一定的规则保存项口源程序的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到项口各个板块的任何版本。为保障公司源代码和开发文档安全不被泄漏，保证选代码的完整性，明确源代码控制管理流程，特制定此管理办法。 1.2适用部门本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 1.3管理部门源代码直接控制管理部门为软件部。 1.4控制范围本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.5角色与职责所有项U成员都必须遵照版本控制规则操作各个项U板块。 1.6版本管理工具VirsualSVN 用此工具对项口开始阶段的开发，和项U中期的变更进行版本的管理。避免发生版本丢失或混淆等现象，详细使用方法见：《Virsual SVN操作细则》1.7项目各板块版本变迁规则各板块的状态有3种-“草稿” （Dralt）. “正式发布” （Released）和 “正在修改” （Changing）各板块状态变迁如图所示：吃賈项状态变迁如圈所示; 各板块刚建立时其状态为“草稿”。各板块通过评审（试用）后，其状态变为“正式发布”。此后若更改各板块源代码，必须填写“版本变更情况表”及“版本变更状态跟踪表”,且版本状态变为“正在修改”,修改后通过审批（试用）其状态乂为“正式发布” O以此循环。二.SVN管理规范 2.1帐号密码的配发规则根据岗位需要，针对不同人员，设置不同权限。遇岗位变更，随时增加删除权限。

公司软件管理规范

XXXXXX有限公司文件制订（修订、作废）申请单NO.: 表格编码：

1. 目的为规范公司软件、程序的管理，确保开发、使用、变更等过程得以受控，根据本公司实际情况，特制定本规范。 2. 适用范围本规范适用于公司所有自主开发、外购、客供软件、程序的管理。（如无特别说明,本规范内“软件”包含软件、程序） 3. 软件分类: 3.1产品源程序: 由研发部软件开发工程师编写，实现产品功能的烧录文件。 3.2 ATE测试软件及测试程序：是指由信息技术部负责编写的配套ATE硬件使用的产品测试软件平台,及在此平台下针对不同型号产品编写的测试程序。 3.3 设备应用程序: 是指工程部在设备操作系统下针对不同产品型号编写的对应程序（ATE除外）。如：打码程序、贴片程序、SPI检测程序、AOI检测程序、分板程序、回流焊程序、X-Ray 测试程序等。 3.4管理应用软件: 是指企业使用的电子化管理工具或系统平台。如:ERP系统、品质管理系统、SPC系统、生产报表系统、电子看板系统、绩效管理系统、项目管理系统等 3.5办公软件：Windows、office、Coremail、PDM、AutoCAD、杀毒软件等。 4、职责定义: 原则上公司各部门均可依据自身需求提出软件申请，由技术部门进行开发，交由使用部门进行管理，异常无法解决时,可向技术部门寻求技术支援。具体定义如下： 4.1 需求提出部门:依据公司或者部门的实际情况,提出软件需求申请。软件需求多由软

件使用部门提出，但也可以由其它部门提出。 4.2使用/管理部门:对提出的申请进行评估,确定需求后向开发部门发起正式申请;在软件验收合格后负责日常的管理、维护等；当异常时且无法解决时，及时向开发部门反馈,并要求协助处理。 4.3开发部门:对于使用/管理部门提出的申请进行评估,确定执行方案,并最终完成软件开发；开发部门也负责后期的技术支援。 4.4监控部门:负责对软件验收完成后的使用过程进行监控，确保不出现使用错误,维规操作,使用非法软件及机密软件外流等。 4.4软件管理职责对照见下表：分类开发部门使用/管理部门监控部门产品源程序研发部工程部品质部 ATE测试软件及测试程序信息技术部工程部品质部设备应用程序工程部工程部品质部管理应用软件信息技术部使用部门信息技术部办公软件信息技术部使用部门信息技术部 5.软件管理规范： 5.1软件申请、开发、使用管理流程图：（如下图）

产品版本管理规范

基于Tortoise SVN的软件产品版本管理规范[草稿]

目录 1. 引言 (1) 1.1. 目的 (1) 1.2. 范围 (1) 1.3. 术语定义 (1) 1.4. 参考资料 (2) 1.5. 版本控制记录 (2) 1.6. 版本更新记录 (2) 1.版本管理 (4) 2.1. 版本标示方法 (4) 2.1.1. 正式版本 (4) 2.2. 目录结构 (5) 2.3. 文档的存放 (6) 2.3.1. 开发文档的存放 (6) 2.3.2. 源代码的存放 (6) 2.3.3. SQL的语句存放 (7) 2.3.4. 发行文档的存放 (7) 2.4. 配置管理流程 (7) 2.5. 权限控制的管理 (8) 2.更新管理 (9) 3.1. 源程序的修改 (9) 3.2. 版本升级 (10) 3.2.1. 版本升级原则 (10) 3.2.2. 新版本发布 (11) 3.3. 文档的变更 (11) 3.备份管理 (12) 4.版本工具Tortoise SVN的使用 (13)

1.引言版本控制就是对软件开发过程中所创建的配置对象不同版本进行管理，保证任何时间都可以取到正确的版本以及版本的组合。版本控制的主要功能是记录开发过程中的每一次修改，让开发的工作可以随时检查过往历史记录和获得正确版本，是系统的成长记录。 1.1.目的本文档的编制是为了规范产品部、研发部、测试部对软件产品版本的管理。 1.2.范围本文档为产品部、研发部、测试部的管理员提供有关版本管理规范的相关内容，包括： ●●●●版本标识方法软件系统数据的存放文档的修改控制文档的备份制度 1.3.术语定义 SCM 软件配置管理（Software Configuration Management）缩写SVM 软件版本管理（Software Version Management）缩写 SVN 一个开源的版本控制系统Subversion. 文档

软件版本管理规范标准[详]

软件版本管理规第一章目的本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象包括但不限于：项目总体计划可行性研究报告开发计划需求说明书需求设计原型设计说明书系统开发变更申请单系统管理手册用户操作手册培训计划培训记录源程序支持系统运行的配置文件存储过程脚本测试计划测试用例测试脚本测试报告上线计划

上线申请版本维护日志 4.2. 配置库的目录结构每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）

软件项目代码编码规范

变更履历

目录 1总则 (4) 2源代码完整性保障 (4) 3源代码的授权访问 (4) 4代码版本管理 (5) 4.1系统初验 (6) 4.2试运行 (6) 4.3系统终验 (7) 4.4系统验收标准 (7)

1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 3源代码的授权访问 1、源代码服务器对于共享的SVN库的访问建立操作系统级的，基于身份和口令的访问授权。第十条在SVN库中设置用户，并为不同用户分配不同的，适合工作的最小

源代码管理规范

1源代码管理 (1) 总则 (1) 源代码完整性保障 (1) 源代码的授权访问 (2) 代码版本管理 (2) 源代码复制和传播 (5) 系统测试验收流程 (5) 系统初验 (6) 试运行 (6) 系统终验 (6) 应用系统验收标准 (8) 文档评审通过标准 (9) 确认测试通过标准 (9) 系统试运行通过标准 (10)

1代码管理总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规定

上海精佑通信技术有限公司企业标准（管理标准） Q/HT 0001–2005 软件版本管理规定 V1.04 2005-04-11 发布 2005-04-11实施

上海精佑通信技术有限公司目录 1范围 (4) 2术语和定义 (4) 2.1软件 (4) 2.2产品软件 (4) 2.3生产支持软件 (4) 3软件版本命名规则 (5) 3.1软件版本命名组成 (5) 3.2手机软件版本命名 (5) 3.3模块软件版本命名 (5) 3.4手机PC侧软件版本命名 (6) 3.5模块PC侧软件版本命名 (7) 3.6手机生产支持软件版本命名 (7) 3.7模块生产支持软件版本命名 (8) 3.8公用于所有手机和模块的软件版本命名 (9) 3.9无线上网卡相关软件版本命名 (9) 3.10无线上网卡驱动软件版本命名 (10) 3.11正式版本号的升级规则 (10) 3.12版本的电子文件命名规则 (11) 4软件版本发布流程 (11) 5禁止条例 (14) 6管理条例 (14) 7附录 (14)

上海精佑通信技术有限公司文档版本变更记录：版本号拟制日期拟制人版本描述存档编号 V1.00 2005-4-11 郝军初始版本 V1.01 2005-4-27 郝军1．版本号前增加“V”,用以明显标识版本号 2．版本号和时间之间以下划线分隔 3．增加生产支持软件种类 4．增加无线上网卡生产支持软件、管理器软件和驱动软件命名 5．增加版本发布流程的文字说明 V1.02 2005-7-1 郝军增加手机和模块生产支持软件的类型：射频补丁软件（RFP） V1.03 2005-7-15 郝军更改版本号升级规则，更改资料外发申请表 V1.04 2005-7-26 郝军增加机卡合一版本的命名规则注：1）拟制、审核、会签、批准不走电子流程时，必须用钢笔或签字笔填写，不得用铅笔、圆珠笔填写。

Git源代码管理规范

Git源代码管理规范一、分支管理使用git进行源代码管理，一般将某个项目的所有分支分为以下几条主线： 1.Master 顾名思义，既然名字叫Master，那么该分支就是主分支的意思。master分支永远是production-ready的状态，即稳定可产品化发布的状态。 2.Develop 这个分支就是我们平常开发的一个主要分支了，不管是要做新的feature还是需要做bug fix，都是从这个分支分出来做。在这个分支下主要负责记录开发状态下相对稳定的版本，即完成了某个feature或者修复了某个bug后的开发稳定版本。 3.Feature branches 这是由许多分别负责不同feature开发的分支组成的一个分支系列。new feature主要就在这个分支系列下进行开发。当功能点开发测试完毕之后，就会合并到develop 分支去。 4.release branches 这个分支系列从develop分支出来，也就是预发分支。在预发状态下，我们往往会进行预发环境下的测试，如果出现缺陷，那么就在该release分支下进行修复，修复完毕测试通过后，即分别并入master分支后develop分支，随后master分支做正常发布。

5.Hotfix branches 这个分支系列也就是我们常说的紧急线上修复，当线上出现bug且特别紧急的时候，就可以从master拉出分支到这里进行修复，修复完成后分别并入master和develop 分支。下面这张图将完整展示这一个流程

二、工作原理 Git的工作方式：也就是说，每次提交版本变动的时候，git会保存一个快照(snapshot)。如果文件没有被更改，git也不会再次保存，而是提供一个到原来文件的链接。这样一来，git更像是一个小型的文件系统。此外，git的所有操作都可以是本地的，仅仅在将新版本的内容上传到服务器上时才需要连接网络。

源代码管理规范

代码管理制度 1总则 (2) 2源代码完整性保障 (2) 3源代码的授权访问 (2) 4代码版本管理 (3) 5源代码复制和传播 (4) 6系统测试验收流程 (5) 6.1 系统初验 (5) 6.2 试运行 (5) 6.3 系统终验 (5) 6.4 系统验收标准 (6) 6.5 文档评审通过标准 (7) 6.6 确认测试通过标准 (7) 6.7 系统试运行通过标准 (7)

软件版本管理规范

软件版本管理

目录 1. 引言........................................................ .目的................................................. .范围................................................. .术语定义............................................. .参考资料............................................. .版本控制记录......................................... .版本更新记录......................................... 2.版本管理.................................................... .版本标示方法......................................... 正式版本.......................................... .目录结构............................................. .文档的存放........................................... 开发文档的存放.................................... 源代码的存放...................................... SQL的语句存放 .................................... 发行文档的存放.................................... .配置管理流程......................................... .权限控制的管理....................................... 3.更新管理.................................................... .源程序的修改......................................... .版本升级.............................................

代码版本管理规范_v1.1

XXXXXXXX 代码版本管理规范

历史版本

目录历史版本 (2) 1引言 (4) 1.1目的 (4) 1.2管理工具 (4) 2现状概述 (5) 3现状分析 (5) 3.1现状详述 (5) 3.2目标细化 (6) 3.3SVN版本管理 (6) 3.3.1概述 (6) 3.3.2使用对比 (7) 4完整的实施方案 (9) 4.1开发阶段 (9) 4.2预发布测试阶段 (9)

1引言 1.1目的为了规范和制度化公司的软件版本管理制度，并保障项目开发资料的完整性和安全性，同时明确开发源代码的控制管理流程，特此制定此规范。 1.2管理工具沿用SVN管理工具来进行开发的版本管理，源代码管理和开发资料归档。

2现状概述目前公司研发部门对于代码的版本管理方式较为简单，只是在每次发版后做了基线库存档，导致所有正在开发的需求和项目都在同一个目录里面进行修改，造成每次发版的代码都有可能包含了本次发版以外的内容。这样会造成如下两点影响： ●会有不稳定的因素存在，比如：测试只会对当前需要发版的内容进行测试，但是代码库中同时存在多个版本和项目的代码，对于本次发版无涉及的代码没有进过测试就部署到了服务器上，影响运行的稳定性。 ●一旦出现点问题不好定位，比如：出现问题后通常会优先排查发版涉及的内容，但是部分问题是由于其他项目代码引起的。因此，随着公司和项目规模的壮大，对软件代码版本管理提出了更高的要求。 3现状分析 3.1现状详述当前代码版本管理现状如下： 1.所有的开发都在一个目录里面做，各种需求、项目、代码、文件混杂在一起。 2.提交测试服务器时，只考虑了编译能通过，而没有考虑功能本身有没有完成。 3.测试出bug以后，会在开发目录进行修改，然后再次提交到测试服务器。这时提交的代码就可能包含了他人对其他功能/项目的修改，而测试又只会针对此bug再做测试。这就导致了除了此bug之外的修改可能会没有测试过就直接发布到了服务器上，引起预发布环境不稳定并增加预发布bug数量。总体来说，当前工作流程是：预发布出bug，研发修改，再提交测试，然后预发布测试

项目软件版本号管理规范

历史修改记录一. 目的

1.1软件版本按照一定的规则保存所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确的查找到任何版本。 1.2软件版本规范有利于公司各部门之间的对接工作，有利于公司内部资料统一管理。 1.3本文档是为规范研发部软件版本管理而制定的。二. 范围 2.1本文档为研发部软件开发版本提供有关版本管理规范的相关内容，包括：2.2版本标识方法及管理 2.3版本升级 2.4文档及源码的备份制度 2.5所有研发部软件工程师成员都必须遵照项目软件管理规范操作，公司内部使用按照文档及源码存放备份制度。三. 版本管理 3.1版本号规则 3.1.1每个归档版本都有两个版本号：内部版本号和外部版本号。版本号使用 VP规则，V(Version)是指外部版本号（研发测试版本），P(Patch)是指补丁版本号（可选）。 3.1.2版本号命名：V/B+主版本号+次版本号+修订版本号+日期版本号

3.2版本号修改规则 3.2.1主版本号：当功能模块有较大的变动，比如增加模块或是整体架构发生变化。此版本号由项目决定是否修改。 3.2.2次版本号：相对于主版本号而言，次版本号的升级对应的只是局部的变动，但该局部的变动造成程序和以前版本不能兼容，或者对该程序以前的协作关系产生了破坏，或者是功能上有大的改进或增强。此版本号由项目决定是否修改。 3.2.3修订版本号：一般是Bug 的修复或是一些小的变动或是一些功能的扩充，要经常发布修订版，修复一个严重Bug 即可发布一个修订版。此版本号由项目经理决定是否修改。 3.2.4日期版本号：用于记录修改项目的当前日期，每天对项目的修改都需要更改日期版本号。此版本号由开发人员决定是否修改。如： V8.1.0.XXX (上一级版本号有变动时，下级要归零) 3.3版本号修改举例说明如此时版本号为：V8.1.0.XXX ，此时为内部测试阶段 3.3.1 开发人员修复了测试人员提交的bug并经测试人员测试验证关闭bug 之后，发布到外网时，此时就进入了软件的下一个阶段，版本号可改为： V8.1.1.XXXX ，如当前日期跟上一个版本号的日期不一样，版本号可改为： V8.1.1.XXX。

源代码管理规范

1源代码管理 (1) 1.1总则 (1) 1.2源代码完整性保障 (1) 1.3源代码的授权访问 (2) 1.4代码版本管理 (2) 1.5源代码复制和传播 (5) 1.6系统测试验收流程 (5) 1.6.1系统初验 (6) 1.6.2试运行 (6) 1.6.3系统终验 (6) 1.6.4应用系统验收标准 (8) 1.6.5文档评审通过标准 (9) 1.6.6确认测试通过标准 (9) 1.6.7系统试运行通过标准 (10)

1代码管理 1.1总则 1、为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 2、本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 3、源代码直接控制管理部门为技术开发部。 4、本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 5、本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 1.2源代码完整性保障 1、所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。 2、我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 3、软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的SVN库进行SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行SVNCommit操作，在最终进行SVNCommit操作之前需要再进行SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。

软件版本管理规范19726

软件版本管理规范第一章目的本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用范围所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。此岗位可由开发或测试人员兼任。 3.第四章内容 4.1. 版本管理对象包括但不限于：项目总体计划可行性研究报告开发计划需求说明书

需求设计原型设计说明书系统开发变更申请单系统管理手册用户操作手册培训计划培训记录源程序支持系统运行的配置文件存储过程脚本测试计划测试用例测试脚本测试报告上线计划上线申请版本维护日志 4.2. 配置库的目录结构每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目内部的目录结构建议按下列格式创建。

配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目内部的目录结构： |–projectA

软件版本管理规范标准

软件版本管理规 V1.0.0 文档版本变更记录：

目录前言 (3) 1 围 (4) 2 术语和定义 (4) 2.1 软件 (4) 2.2 产品软件 (4) 2.3 演示软件 (4) 3 软件版本命名规则 (4) 3.1 软件版本命名组成 (4) 3.2 产品软件版本命名 (4) 3.3 演示软件版本命名 (5) 3.4 正式版本号的升级规则 (6) 3.4.1 软件版本升级规则 (6) 3.4.2 演示版本升级规则 (6) 3.5 版本的安装文件命名规则及存放路径 (6) 4 软件版本发布流程 (7) 5 管理条例 (7) 6 附录 (7)

前言为规部门产品软件版本的管理与控制，保证产品版本的有效与质量，制定本标准。本标准由移动金融事业部拟制。本标准于2015年6月首次发布。

软件版本管理规定 1围本标准规定了移动银行事业部产品软件版本的控制与管理。本标准适用于移动银行事业部产品软件版本的控制与管理。 2术语和定义下列定义适用于本标准。 2.1软件指与产品相关的所有软件，可以分为产品软件和演示软件。 2.2产品软件已签订合同，有明确交付日期的产品。 2.3演示软件处于研发阶段，并未正式投入生产的应用。 3软件版本命名规则 3.1软件版本命名组成产品的正式软件版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。产品的演示版本命名由四部分组成。第一部分为主版本号，第二部分为次版本号，第三部分为修订版本号，第四部分为日期版本号。 3.2产品软件版本命名产品软件版本的命名规则如下所示：

(完整版)技术部软件版本管理规范

技术部软件版本规范文档建立/修改记录：版本管理规范【新建项目版本管理部分】 1，项目组接到项目需求， 1.1，开发组出项目设计和开发计划； 1.2，测试在Git中建立空项目(项目名称开会时候会有，没有需要问)，形成master版本，版本设定为V0.0.0。 2，组长发邮件给技术总监，并且抄送给项目经理和测试。邮件内容：开发计划文档url和开发版本号(V0.1.0)，请批准第一阶段(开发计划中会包含)开发。 3，得到批准开发回复后，测试从master(V0.0.0)建立分支版本(V0.1.0)，打开版本参与人员的更新权限，并且将url给组长。 4，组长download项目，上传项目可运行框架，并且更新GIT中的readme文档并通知开发；5，开发者必须按时按功能点来提交(提交时需写相应描述)项目到GIT中，并且push前必须测试，保证代码不能有运行异常，导致无法测试 5.1，Push结束后，开发者继续开发下一个功能点。 5.2，push结束会自动化构建，自动化构建完成后系统会自动通知测试人员进行测试，测试人员需先关闭版本参与人员的更新权限，再按功能点来测试bug，然后更新bug文档和测试用例文档的内容(有无bug都需要更新)，随即打开更新权限并通知组长。 6，开发者下一个功能点提交时，同上要求。 7，第一阶段最后一个功能点提交完毕后，测试者关闭此版本参与者更新权限，然后将此版本(V0.1.0)建分支版本(V0.1.1)并且给出版本url给组长，继续进行测试最后一个功能点bug。8，组长通知组员进行bug（bug一般会比较少，bug很多只能说明开发者开发质量有问题）修改，给出修改版本地址。 9，修改完毕后提交，测试人员再次关权限且测试，如仍然有bug存在，更新相应文档并在相关修改支版本(这里是V0.1.1)中再次建立修改版本(此时是V0.1.2)，随即给出版本url给组长。ps：提交版本如有冲突找组长调节。 10，第一阶段开发完全完成后开始开发第二阶段任务，重复2~9步骤，相应的版本号会变为从V0.2.0开始，同里修改版本号则是V0.2.1/V0.2.2/V0.2.3...... 11，当全部阶段任务完成(指的是开发完成并测试无bug)，测试将最新的修改完成的版本(应该是V0.x.x，x为任意数字)合并到master版本中，此时版本号设定为V1.0.0。测试发邮件给

源代码管理规范

源代码管理规范标准化文件发布号：（9312-EUATWW-MWUB-WUNN-INNUL-DQQTY-

代码管理制度 1总则.................................................................................................. 错误!未定义书签。2源代码完整性保障............................................................................ 错误!未定义书签。3源代码的授权访问............................................................................ 错误!未定义书签。4代码版本管理 ................................................................................... 错误!未定义书签。5源代码复制和传播............................................................................ 错误!未定义书签。6系统测试验收流程............................................................................ 错误!未定义书签。系统初验........................................................................................... 错误!未定义书签。试运行............................................................................................... 错误!未定义书签。系统终验........................................................................................... 错误!未定义书签。系统验收标准................................................................................... 错误!未定义书签。文档评审通过标准........................................................................... 错误!未定义书签。确认测试通过标准........................................................................... 错误!未定义书签。系统试运行通过标准....................................................................... 错误!未定义书签。

(完整版)新媒体平台管理规范

新媒体平台管理规范第一章总则第一条为进一步加强对中心官方新媒体平台（以下简称“新媒体平台”）的规范管理，充分发挥外宣和信息交流的积极作用，树立中心良好形象，制定本规范。第二条新媒体平台是指为中心整体形象传播、业务拓展以及促进与客户间沟通交流等，经中心审批同意，向各类平台运营商申请并使用的各种新媒体信息交流平台，如微信、微博、网络直播平台以及日后新兴的其他新媒体平台等。第三条本办法适用于中心本部，下属公司可参照执行。第二章管理及职责第四条因中心整体形象传播、业务拓展及客户维护等工作需要，各部门可申请在新媒体平台上设立账号。新媒体平台的相关部门包括使用部门与管理部门。使用部门：基于中心整体形象传播需要，在新媒体平台上新设账号的，使用部门为办公室；基于业务拓展或客户维护需要在新媒体平台上新设账号的，使用部门为各业务部门。管理部门：按照新媒体平台的功能定位不同进行划分：用于对中心整体形象进行传播的，管理部门为办公室；用于各部门进行业务传播及客户维护的，管理部门为运营管理部；有关信息技术支持方面的，管理部门为信息中心。第五条新媒体平台相关部门的职责划分：

一、使用部门主要负责所申请新媒体平台账号的日常使用及维护工作，具体包括：（一）经中心审批，同意新设（或注销）新媒体平台账号后，按照平台运营商要求，完成新设（或注销）相关程序，并按要求报管理部门备案；（二）信息审核发布及日常的使用、维护等；（三）结合部门情况建立相应的内部管理机制（包括信息审核、维护管理等）；（四）当新媒体平台账号使用情况发生变化时，及时报管理部门登记备案。二、管理部门职责：（一）办公室主要负责对用于中心整体形象传播的新媒体平台账号进行管理，具体包括： 1.负责将新媒体平台账号的具体信息登记造册（见附件1）以及信息修改备案等； 2.按照平台运营商要求，配合使用部门提供新设（或注销）账号所需的公司资料； 3.对新媒体平台账号进行舆情监控，发现问题及时上报。（二）运营管理部主要负责对各部门用于业务广告及客户维护的新媒体平台账号进行管理，具体包括： 1.当其他部门向中心申请新设（或注销）新媒体平台账号时，提出相关管理意见； 2.负责将新媒体平台账号的具体信息登记造册以及信

源代码及文档管理规范

源代码管理文档管理规范第一章总则第一条为保障公司源代码和开发文档安全，保证源代码的完整，明确源代码控制管理流程，特制定本源代码管理办法。第二条本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。第三条源代码直接控制管理部门为产品管理。原代码的内容为我单位万网工程建站的所有相关网站，模板，四川机构网网站代码以及数据库等。第四条本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。第五条本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。第二章源代码完整性保障第六条所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。第三章源代码的授权访问第七条源代码服务器对于共享的TFS库的访问建立操作系统级的，基于身份和口令的访问授权。第八条在TFS库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接TFS库时必须校验TFS中用户身份及其口令。在TFS库中要求区别对待不同用户的可访问权、可读权、可写权。第九条曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。第四章源代码复制和传播第十条源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录

复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。第十一条源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。第十二条源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。第十三条任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。第十四条对于因合作需要，需要向外复制、传播、分发源代码的，不论是全部还是部分代码和资料，均必需和对方签订技术、源码的保密协定，明确对方应当承担的对源码保密的责任和义务。第十五条所有已有的开发文档与当前的代码进行统一管理。第十六条新开发的项目和系统验收时必须与同相关的开发文档同时进行验收。第五章开发文档管理规范第十七条所有已有的开发文档与当前的代码进行统一管理第十八条本规范执行日之后的所有项目的开发必须按开发的基本规则输出开发文档进行备案。第十九条开发周期在1-3个月以内的项目开发文档保密时效为6个月，开发周期在3个月以上的为一年，保密时效计时为项目结束成功验收之后开始。第二十条在项目开发中任何以不得未经授权向外发布、流传开发相当的任何文档。

某软件有限公司文档版本管理规范

密级：内控研发本部版本管理规范 V1.0 浪潮集团山东通用软件有限公司

目录文档类别使用对象 (2) 1．引言 (3) 1.1目的 (3) 1.2范围 (3) 1.3术语定义 (3) 1.4参考资料 (4) 1.5版序控制记录 (4) 1.6版本更新记录 (4) 2．版本管理 (5) 2．1版本标识方法 (5) 2．1．1正式版本 (5) 2．1．2特殊版本 (5) 2．2目录结构 (5) 2．3文档的存放 (7) 2.3.1 当前版本和历史版本的存放 (7) 2.3.2 开发文档的存放 (7) 2.3.3 源代码的存放 (7) 2.3.4 SQL语句的存放 (7) 2.3.5发行文档的存放 (8) 2．4权限控制管理 (8) 3．更新管理 (8) 3．1源程序的修改 (8) 3．2已发布版本的维护及修改 (9) 3．3外出人员对产品的修改 (9) 3．4版本升级 (12) 3.4.1 版本升级原则 (12) 3.4.2 新版本的发布 (12) 3.4.3 安装盘制作步骤 (13) 4．备份管理 (13) 5．用户版本管理 (14)

文档类别使用对象文档类别该文档是为浪潮通软公司研发本部各产品部、事业部提供一个版本管理规范性文件。使用对象该文档使用对象为浪潮通软公司研发本部各部门经理及版本管理人员，以及其他相关人员。未经管理过程改善部书面许可，该文档不得提供给上述规定对象以外的人员阅读或使用。

1．引言 1.1目的本文档是为规范公司研发本部各产品部、事业部版本管理而制定的。 1.2范围本文档为各产品部、事业部版本管理员提供有关版本管理规范的相关内容，包括： ●版本标识方法 ●软件系统数据的存放 ●文档的修改控制 ●文档的备份制度 1.3术语定义 SCM Softwere Configuration Management缩写 SVM Software Version Management缩写文档一种数据媒体和其上所记录的数据。配置管理标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。软件配置软件的具体形态在某时刻的瞬时影像。配置项软件配置管理的对象称为配置项，如：系统规格说明书，项目开发计划，用户手册，源码。基线软件生存周期中各开发阶段末尾的标记，它的作用是把各阶段工作的划分更加明确