版本控制规范.docx

版本控制规范简介目的版本控制规范用于确定软件配置项的命名与版本号管理的规则，以确保清楚地、唯一地标识软件的各个组成部分及其状态，并建立这些部分之间的一致性关系。范围版本控制的范围包括：源代码：用计算机编程语言编写的源代码文件文档：需求文档、架构设计文档、数据库设计文档等描述软件功能和结构的技术文档；项目计划等项目管理文档以及各种测试文档和用户文档产品包：将源代码进行编译得到的可运行的软件系统产品标识在每个软件产品立项时建立该软件产品的标识，以唯一地代表一个软件产品或项目，产品标识也称为项目标识。产品名称新产品立项时，为产品赋予产品名称；当已有产品升级时，则沿用前一版本产品的名称。产品名称包括：产品中文名称：如：订单管理系统，仓库管理系统等等产品英文名称：如：Order Management System，Warehouse Management System产品英文简称：如：OMS，WMS产品名称用于相关文档的编写和产品的发布。产品名称不是某一产品的唯一标识，必须与版本号一起用才能标识特定产品。版本号版本号用来标识开发、测试、交付阶段的不同状态的产品，版本号格式为：主版本号.次版本号.小版本号-[Build号]主版本号：立项时设置，在整个项目开发过程中不改变次版本号：立项时设置，在整个项目开发过程中不改变小版本号：立项时设置，在整个项目开发过程中不改变Release号：又叫Build号，内部测试开始之前设置，初始值为0，此后每产生一次小的修改，Release号+1版本号的一般形式如：1.0.7-101，2.0.0-900版本规范版本号设置规则主版本号设置时间：产品立项时设置设置规则：新产品立项，主版本号为1产品构架发生改变，主版本号+1产品主要组件（比如订单处理框架）进行重大修改，主版本号+1产品对外接口协议发生更改，主版本号+1次版本号设置时间：产品立项时设置设置规则：新产品立项，次版本号为0为处理产品Bug或改进现有功能/性能，对现有功能模块做大的修改，但不增加新的功能模块，副版本号+1为增加产品功能，在原版本产品上增加新的功能模块，而产品的主体构件未做重大修改，并且产品的主体构件之间的接口协议也未做修改，副版本号+1为适应不同用户需求，对产品进行更改，而产品的主体构件未做重大修改，并且产品的主体构件之间的接口协议也未做修改，副版本号+1当主版本号变更时，副版本号同时置0小版本号新产品立项，小版本号为0修复Bug或改进现有功能，但不对现有功能模块做大的修改，不增加新的功能模块，小版本号+1当次版本号变更时，小版本号同时置0Build号设置时间：产品开发结束，内部测试开始之前设置规则：Release号初始值为0测试过程中，每进行一次修改，Release号+1版本管理trunk任何时候trunk里包含的都是必威体育精装版的开发代码。这里的代码将会工作到下一个主要发布版本。trunk应该只被用来开发将会成为你的下一个重要版本的代码。不要给trunk加上版本号和发布名称。仅需要保证trunk在任何时候都处于“开发模式”。branches有几种不同类型的分支。在branches的目录里，可以为更多具体的目标创建路径，像即将发行版本。Brahches可以包含了trunk在不同发展阶段的副本。Release Branches当trunk达到准备发布的阶段时（或者你想冻结新特色的添加时），应该创建一个release branches。 Release branches只是当前trunk的一个副本。这个branches可以被单独的签出，也可以启动branches和基于此版本的项目。还可以使用此分支在测试期间修复Bug。这种方式能够保证trunk继续开发，而不会被发布某个具体的版本所干扰。因此当准备发布一个新版本时，不会影响trunk增加新的功能。Bug fix branches分支也可以用于处理trunk或release branches里发现的严重的Bug。这些Bug很复杂，不能在一次提交时就修复他们。因此为了集中精力修正此错误，应该为此问题创建一个新的分支。这样就不会影响trunk 和 release branches的继续进行，并且也不会因为发现新的Bug 和测试而干扰此Bug 的修复。Experimental branches有时想将某个新技术引进项目。但是不想影响到整个项目。比如想把web应用从spring3x改为spring4x。要花多少时间？在这期间trunk停止使用？直到把所有到spring的转换做完。可能Spring4x对程序变动较大，应该创建一个实验分支。这样就可以在分支里进行更改，如果失败了，不影响当前应用，实验分支可以抛弃。如果成功，可以很容易的将其合并到trunk。tagstags用来备份代码，通常是readonly的，不被