开发部SVN使用规范.docxVIP

开发部SVN使用规范 开发部SVN使用规范 PAGE / NUMPAGES 开发部SVN使用规范 XXXX股份有限企业 开发部 SVN使用规范 拟制 日期 审查 日期 赞同 日期 1、目的： 本制度为研发部 SVN配置管理的准则和依照， 全部与 SVN配置管理的行为都一定依照并 听从于本制度。 2、合用范围： 本制度合用于研发部全体职工。 3、名词： 配置管理：是指对项目生计期过程中的各阶段产品和最后产品演化和改正的管理。 改正控制组：是配置项改正的看管组织。 配置项：指哪些应当归入配置管理之下，成为受控的工作产品最小单位项。 基线：基线是经过正式评审和认同，作为后续工作依照的配置项会合。 配置审计：配置审计主假如考证配置项的完好性和配置项的一致性。 4、职责： 3.1 改正控制组 赞同成立基线和表记配置项。 赞同基线的公布。 评审与赞同基线的改正。 赞同由基线库生成产品。 3.2 项目经理 辅助配置管理员拟订配置管理计划。 定义基线和配置项。 提出公布申请。 推进项目的配置管理工作。 3.3 项目构成员 提交配置项内容。 3.4 配置管理员 拟订和保护配置管理计划。 成立和保护配置管理系统。 表记配置项。 公布基线。 履行基线审计。 表记、保留并散发配置状态报告。 从基线库公布产品。 3.5 质量保证人员（ QA ） 依照计划和过程检查配置管理活动及其工作产品。 报告检查中发现的问题，追踪问题直至封闭。 5、控制要乞降方法： 操作流程 Repository Network 网络 版本库 检出、提交  Workin g Copy Workin g Copy 当地工作副本 第一用户从版本库经过网络 “检出” 到当地工作副本中， 而后，在当地工作副本中进行 增添、改正、删除文件后“提交”到版本库中，假如当地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 帐号注册、权限申请 用户帐号注册： 新进职工没有 SVN帐号，经过邮件联系 SVN管理员， 邮件正文注明申 请 SVN一般帐号，管理员办理完帐号注册事宜后，会邮件答复。 注：一般帐号，只对个人目录有读取权限。 权限的申请： 依据职工所参加的项目， SVN管理员对其开放相应目录的读、写权限。 账号注销：职工辞职后，对其账号进行注销。 操作规范 每天进行开发工作以前更新代码，下班时提交代码。 各职工需切记各自的账户和密码， 不得向他人透漏， 禁止使用他人账户进行 SVN各项操作。 不要签出整个目录，除非特别必需，不该同时签出过多的项。 文件提交时要求一定提交说明， 注明有关改正信息， 日记信息描绘的越详尽越好， 让项目组其余成员在看到标明后不用详尽看代码就能认识你所做的改正。 代码改动实时提交，防止丢掉当地改正后没法恢复。 在提交以前要编译代码并修正错误。 要保证新增添的文件同时被提交， 不然只在你当地能正常工作，致使其余人不可以编译经过。 提交以前要测试所改变的应用，测试改变后的成效能否达到预期的目的。 多次检查提交的内容。 提交以前应先做 SVN更新或与资源库同步， 注意到 SVN对于矛盾、 错误的信息。 资源库同步会告诉你将要提交的内容与资源库内容之间的差异， 确认它们 能否是你真实想要提交的。 9. 假如他人和自己改正的是同一个文件，那么 Update 时会自动进行归并，假如改正的是 同一行， 那么归并时会产生矛盾， 这类状况就需要同以前的开发人员联系， 两个人一同 磋商解决矛盾， 解决矛盾以后， 需要两人一同测试保证解决矛盾以后， 程序不会影响其 他功能。 在更新时注意所更新文件的列表， 假如提交过程中产生了更新， 则也是需要从头编译而且达成自己的一些必需测试， 再进行提交。 这样既能认识他人改正了哪些文件， 同时也能防止 SVN归并错误致使代码有错。 提早宣告改正计划。 当你计划进行改正， 需要影响到 SVN里的很多文件时， 先经过邮件或许当面通知其余开发者。 比如，改正基层数据库模块时， 有可能影响到业务逻辑层调用数据库模块的地方。这样其余开发者会有准备，也会对改正提出建议和建议。 每次提交尽量是一个最小粒度的改正。比方一个小功能提交一次。 不要提交不可以经过编译的代码。 代码在提交以前， 第一要确认自己可以在当地编译。如 果在代码中使用了第三方类库， 要考虑到项目构成员中有些成员可能没有安装相应的第 三方类库。 提交时注意不要提交当地自动生成的文件，提交的文件一定是开发者共用的程序言件， 程序编译中产生的中间文件或文件夹，如/Debug/ 、 /Release/ 、 *.ncb 、 *.obj 、 *.o 、 、 /build/ 、 *.class 、 /classes/ 、 /data/ 等不要提交到 SVN