文档介绍：软件版本管理规范
第一章目的
本规范详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等内容，使
软件项目版本管理流程化并规范化，确保在系统开发和实施过程中项目的完整性和一致性。
第二章适用范围
所有系统开发及实施项目的软程中进行测试，修改好一个或多个bug，需要测试工程师验证时。从测试分支到发布分支的迁移，由配置库管理员操作。迁移的时机有：。
对于每个项目从测试分支到发布分支的迁移，配置库管理员要建立分支迁移日志，并详细记录。

软件系统迁移到发布分支后，生成新的版本。
每个系统新的版本不仅以分支形式存在于配置库中，并且要以独立压缩包形式备份。
版本的命名规则为，[.N4][」[T/R5]_YYYYMMDD
N1是系统编号。当项目整体重新设计时，N1加1,基数为1
N2是模块编号。当模块重新设计时，N2加1,基数为0
N3是功能编号。当项目增加某一功能，或某一功能需要修改时，N3加1,基数为
0
N4是BUG编号。当项目的BUG被修复时，N4加1,基数为0
T/R5中的T/R分别对应Test/Release。当项目发布时为R，当项目提交测试时为
T，T/R5数值基数为0,以发布/测试提交顺序递增加1。
YYYYMMDD代表生成版本的实际年月日，如：20160202
版本基线定义
公司首次采用版本管理规范时,可以采取下列方法定义一个基线版本。获取各项目最新的源程序、配置文件和文档,形成发布分支、测试分支和开发分支。
对每个项目的提测和发布分支都生成一个版本基线,如：
。
第五章版本提交准则
提交之前先更新
更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且自己测试之后,谨慎地提交。
如果在修改的期间其他同事也更改了同一个文件，那么update更新时会自动进行合
并,如果修改的是同一行或者二者修改差异过大,那么合并时会产生冲突。这种情况
就需要同之前的开发人员联系，两人一起协商解决合并冲突。解决合并冲突之后，还需要两人一起测试，以保证解决冲突之后，各自的程序不会受到影响。
在更新时注意所更新文件的列表，如果提交过程中产生了更新，则需要重新编译并且再次完成单元测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免合并错误导致代码有错。
保持原子提交
为确保在需要时可以随时回溯代码版本，每次提交的代码只能包含实现一个独立、完整功能所必需的代码，不能夹带提交其他与此功能不相关的代码。为尽早提交，也可以将此独立、完整功能分解为若干小细节功能，分别开发并提交所必需的代码，但必须确保多次提交的功能代码组合在一起，完全实现此独立、完整功能。
仅提交自己修改的部分，最好不要一下子将整个项目提交。
每完成一个独立、完整的功能后，最好尽早提交，以免后续更改时出现bug，无法恢复到正常代码。
每次提交的间歇尽可能地短，以几个小时的开发工作为宜。我们提倡多提交，也就能多为代码添加上保险。为做到尽早提交，在开发功能模块的时候，先将功能分解成一个个独立的、不可再分割的小细节功能，分别完成。每完成一个并通过单元测试，就提交一次。在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。

一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件
屏蔽提交（，，Debug,Release,Obj等编译文件夹及其下文件，以及其他的一些自动生成，同编译代码无关的文件）。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件，如果不小心签入了，需要从配置库中删除，以免其他同事在更新后就可能与本地的环境冲突从而影响大家的工作。
不要提交不能通过编译的代码代码在提交之前，首先要确认自己能够在本地编译通过，并且代码在提交前已经通过自己的单元测试。
如果在代码中使用了第三方类库，要把相应类库文件统一存储在代码相应目录中并提交，以免项目组成员中有些成员可能没有安装相应的第三方类库，从而在更新代码后引起代码运行错误。
不要提交自己不明白的代码代码在提交之后即被项目成员所分享。如果提交了不明白的代码，自己看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保对这个代码有一个很清晰的了解（必要时应有对应文档说明）。
并行开发（同一模块）前沟通如果开发小组采用并行开发模式开发同一模块功能，在开发前，需要对协作开发进行