研发规范-版本管理规范

XX公司密级密级内部资料XX公司文档名称文档编号起草时间版本管理规范2022-6姓名2022-6姓名部门文档信息发布版本起草人签发人文档修改记录序号修改时间修改人主要修改存档版本123456789XX公司版本管理规范1目的 42合用范围 43版本管理规范 43.1版本管理工具 43.2版本库目录结构 43.3版本命名规范 5 3.4版本提交规范 5XX公司1目的标识、控制和追踪软件开辟和实施过程中产生的各种软件产品版本。合用于研发中心相关项目和产品所有软件文档和源代码版本的管理。采用Subversion(SVN)进行版本管理。下所示：第一层目录为wasu_XXXX(XXXX为项目或者产品名称缩写)，每一个项目或者产品的下层目录结构(第trunk主开辟目录release_tags发布版本存档目录(不允许修改)这三个目录每一个目录下层目录结构(第三层目录)统一如下：doc存放开辟过程中的文档发、测试、文档、制作安装程序、打包等)结束后，代码处于冻结状态(人为规定)。此时应该此时，如果发现了上一个已发行版本(ReleasedVersion)有一些bug，或者一些很急迫的功能要求，而正在开辟的版本(DevelopingVersion)无法满足时间要求，这时候就需要在上一个版本上进行修改了。应该基于发行版对应的tag，做相应的分支(branch)进行开辟。1.1.0开辟完毕，代码冻结此时的目录结构为此时的目录结构为XX公司步操作，要根据具体情况)名称新产品立项时，为产品赋予版本库中的产品名称；当已有产品升级时，则沿用前一版本产品版本库中的产品名称暂定为wasu_XXXX(XXXX为产品中文名称首字母组成或者产品英文名称)，作为版本库该产品的首层目录名。版本号版本号用来标识发布产品，版本号格式为：<主版本号>.<副版本号>主版本号：立项时设置副版本号：立项时设置本标识当产品因为针对不同项目浮现分支而又不需要合并到主版本或者与主版本功能有冲突的或者基于建立目录，后续针对分支的修改都在该分支内完成；如果分支作为老版本bugfix而又修复完成版本号+1>的目录作为版本发布目录，内容从分支目录下copy。先更新，再提交SVN更新的原则是要随时更新，随时提交。当完成为了一个小功能，能够通过编译并且自己测试之后，谨慎地提交。自己更改的是同一个文件，那末update时会自动进行合并，如果修改的是同一行，那末合并时会产生冲突，这种情况就需要同之前的开辟人员联系，两个人一起商议解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。XX公司在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免SVN并错误导致代码有错。多提交以每完成一个UI界面的修改或者设计，就提交一次。在开辟功能模块的时候，可以每完成一个bug，也就提交一次。我们提倡多提交，也就能多为代码添加之保险。不要提交不能通过编译的代码代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域行每次提交必须书写明晰的标注在一个项目组中使用SVN，如果提交空的标注或者不切当的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解提交时注意不要提交本地自动生成的文件文件.obj,.class等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交自己不明白的代码代码在提交入SVN之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你三方代码之前，确保你对这个代码有