svn源代码管理规范

svn源代码管理规范篇一：开发部 SVN使用规范XXXX 股份有限公司 开发部 SVN使用规范 1、目的： 本制度为研发部 SVN配置管理的准则和依据，所有与SVN配置管理的行为都必须遵照并服从于本制度。 2、适用范围： 本制度适用于研发部全体员工。 3、名词： 配置管理：是指对项目生存期过程中的各阶段产品和最终产品演化和变更的管理。 变更控制组：是配置项变更的监管组织。 配置项：指哪些应该纳入配置管理之下，成为受控的工作产品最小单位项。 基线：基线是经过正式评审和认可，作为后续工作依据的配置项集合。 配置审计：配置审计主要是验证配置项的完整性和配置项的一致性。 4、职责： 变更控制组 批准建立基线和标识配置项。 批准基线的发布。 评审与批准基线的更改。 批准由基线库生成产品。 项目经理 协助配置管理员制定配置管理计划。 定义基线和配置项。 提出发布申请。 推动项目的配置管理工作。 项目组成员 提交配置项内容。 配置管理员制定和维护配置管理计划。 建立和维护配置管理系统。 标识配置项。 发布基线。 执行基线审计。 标识、保存并分发配置状态报告。 从基线库发布产品。 质量保证人员（QA） 按照计划和过程检查配置管理活动及其工作产品。 报告检查中发现的问题，追踪问题直至关闭。 5、控制要求和方法： 操作流程 版本库 本地工作副本 首先用户从版本库通过网络“检出”到本地工作副本中，然后，在本地工作副本中进行增加、修改、删除文件后“提交”到版本库中，如果本地工作副本中版本较系统版本过时，用户使用“更新”功能与系统上版本保持一致。 帐号注册、权限申请 1. 用户帐号注册：新进员工没有 SVN帐号，通过邮件联系 SVN管理员，邮件正文注明 申请 SVN普通帐号，管理员处理完帐号注册事宜后，会邮件回复。 注：普通帐号，只对个人目录有读取权限。2. 权限的申请： 根据员工所参与的项目，SVN 管理员对其开放相应目录的读、写权限。 3. 账号注销：员工离职后，对其账号进行注销。 操作规范 1. 每日进行开发工作之前更新代码，下班时提交代码。 2. 各员工需牢记各自的账户和密码，不得向他人透漏，严禁使用他人账户进行 SVN各项 操作。 3. 不要签出整个目录，除非特别必要，不应同时签出过多的项。 4. 文件提交时要求必须提交注释，注明相关修改信息，日志信息描述的越详细越好，让项 目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。 5. 代码变动及时提交，避免丢失本地修改后无法恢复。 6. 在提交之前要编译代码并修正错误。要保证新增加的文件同时被提交，否则只在你本地 能正常工作，导致其它人不能编译通过。 7. 提交之前要测试所改变的应用，测试改变后的效果是否达到预期的目的。 8. 多次检查提交的内容。提交之前应先做 SVN更新或与资源库同步，注意到 SVN关于冲 突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别，确认它们是不是你真正想要提交的。 9. 如果别人和自己更改的是同一个文件，那么Update时会自动进行合并，如果修改的是 同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。 10. 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并 且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免 SVN合并错误导致代码有错。 11. 提前宣布修改计划。当你计划进行修改，需要影响到 SVN里的许多文件时，先通过邮 件或者当面通知其他开发者。例如，修改底层数据库模块时，有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备，也会对修改提出意见和建议。 12. 每次提交尽量是一个最小粒度的修改。比如一个小功能提交一次。 13. 不要提交不能通过编译的代码。代码在提交之前，首先要确认自己能够在本地编译。如 果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。14. 提交时注意不要提交本地自动生成的文件，提交的文件必须是开发者共用的程序文件， 程序编译中产生的中间文件或文件夹，如/Debug/、/Release/、*.ncb、*.obj、*.o、 、/build/、*.class、/classes/、/data/等不要提交到 SVN里。 15. SVN管理员需对 SVN的所有项目定期备份。 16. SVN的资料不允许公开给其他部门人员，确实要分发的，必须通过总经理同意。 篇二：源代码及文档管理规范第一章 总则 第一条 为保障公司源代码和开发文档安全不至于泄露，保证源代码的完整，明确源代码控制管理流程，特制定此管理办法。 第二条 本办法适用于所有涉及接触源代码的各部门各岗位。所涉及部门都必须严格执行本管理办法。 第三条 源代码直接控制管理部门为研发部。 第四条 本办法管理重点在于控制管理源代码的完整性，不被非授权获取，不被非授权复制和传播。 第五条 本办法所指源代码不仅限于公司开发人员自行编写实现功能的程序代码，而且还包括相应的开发设计文档及用于支撑整个系统运行所必须具备的第三方软件、控件和其它支撑库等文件。 第二章 源代码完整性保障 第六条 所有软件的源代码文件及相应的开发设计文档均必须及时加入到指定的源代码服务器中的指定库中。第七条 我们研发的产品软件运行所必须的第三方软件、控件和其它支撑库等文件也必须及时加入源代码服务器中指定的库中。 第八条 软件开始编写或者调整代码之前，其相应的设计文档和代码必须先从相应的 SVN库进行 SVNUpdate操作。软件编码或功能调整结束测试正确无误后，相应的源代码必须进行 SVNCommit操作，在最终进行 SVNCommit操作之前需要再进行 SVNUpdate操作，查看是否有冲突产生，如果有冲突产生需要和冲突相关人一并解决冲突。 第三章 源代码的授权访问 第九条 源代码服务器对于共享的 SVN库的访问建立操作系统级的，基于身份和口令的访问授权。 第十条 在 SVN库中设置用户，并为不同用户分配不同的，适合工作的最小访问权限。要求连接 SVN库时必须校验 SVN中用户身份及其口令。在 SVN库中要求区别对待不同用户的可访问权、可读权、可写权。 第十一条 曾经涉及、触及源代码的计算机在转作它用，或者离开研发部门之前必须由网络管理人员全面清除计算机硬盘中存储的源代码。如果不能确定，必须对计算机中所有硬盘进行全面格式化后方可以转做它用或离开研发部门。 第四章 源代码复制和传播 第十二条 源代码向研发部门以外复制必须获得总经理的书面授权。并必需记录复制人、批准人、复制时间、复制目的、文件流向、文件版本或内容。 第十三条 源代码以任何介质形式进行存储的备份，必须由专人负责保管。对于这些介质地借阅，用于研发部内部使用的必须获得研发部经理的授权，对于用于研发部以外使用的必须获得总经理的书面授权。 第十四条 源代码的借阅、复制必须进行详细的登记，必需记录借阅人、批准人、借阅时间、 借阅目的、文件流向、文件版本或内容、归还时间。第十五条 任何纸质材料的借阅都必需记录借阅人、批准人、借阅时间、借阅目的、文件流向、文件版本或内容、归还时间。 第十六条 对于因合作需要，需要向外复制、传播、分发源代码的，不论是全部还是部分代码和资料，均必需和对方签订技术、源码的保密协定，明确对方应当承担的对源码保密的责任和义务。 篇三：SVN 源代码管理器SVN 源代码管理器 svn 的几个概念： 一、repository 仓库 二、Workspace 工作台 三、Delta 增量 四、Baseline(HEAD) 基线 五、Branch 分支 六、Label(Tag) 标签 工具的安装 SVN 分成两部分 服务器：Tigris svn 客户端：Tortoise svn 服务器安装