svn提交注释规范

svn 提交注释规范篇一：SVN 版本管理与提交代码规范SVN 版本管理，提交代码规范 项目开发要求： 1、工作目录要及时更新，不要和 SVN 服务器有太大的差别 2、提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交 3、提交代码之前先在本地进行测试，确保项目能编译通过，且能够正常运行，不可盲目提交 4、必须保证 SVN 上的版本是正确的，项目有错误时，不要进行提交 SVN 注意事项，请严格按照操作顺序操作，避免提交代码导致重大事故： 一提交之前先更新 更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己 测试 之后，谨慎地提交。2. 如果在修改的期间别人也更改了 svn 的对应文件，那么 commit 就可能会失败。如果别人和自己更改的是同一个文件，那么 update 时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突 之后，程序不会影响其他功能。 3. 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免 SVN 合并错误导致代码有错 二保持原子性的提交 每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改 UI 界面的时候，可以每完成一个 UI 界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug 的时候，每修改掉一个 bug 并且确认修改了这个 bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。三提交时注意不要提交本地自动生成的文件 一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交（例如 eclipse 中的.classpath 文件等） 。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。 四不要提交不能通过编译的代码 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。五不要提交自己不明白的代码 代码在提交入 SVN 之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。 六提前协调好项目组成员的工作计划 项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前，如果有可能，先跟工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。 七对提交的信息采用明晰的标注（写注释） 在一个项目组中使用 SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。八慎用锁定功能 在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash 文件等）时，才适当的采用锁定操作。 篇二：SVN 版本管理,提交代码规范项目开发要求： 1、工作目录要及时更新，不要和 SVN 服务器有太大的差别 2、提交代码时，如果出现冲突，必须仔细分析解决，不可以强行提交 3、提交代码之前先在本地进行测试，确保项目能编译通过，且能够正常运行，不可盲目提交 4、必须保证 SVN 上的版本是正确的，项目有错误时，不要进行提交 SVN 注意事项，请严格按照操作顺序操作，避免提交代码导致重大事故： 一提交之前先更新 更新的原则是要随时更新，随时提交。当完成了一个小功能，能够通过编译并且自己 测试 之后，谨慎地提交。2. 如果在修改的期间别人也更改了 svn 的对应文件，那么 commit 就可能会失败。如果别人和自己更改的是同一个文件，那么 update 时会自动进行合并，如果修改的是同一行，那么合并时会产生冲突，这种情况就需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突 之后，程序不会影响其他功能。 3. 在更新时注意所更新文件的列表，如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。这样既能了解别人修改了哪些文件，同时也能避免 SVN 合并错误导致代码有错 二保持原子性的提交 每次提交的间歇尽可能地短，以几个小时的开发工作为宜。例如在更改 UI 界面的时候，可以每完成一个 UI 界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug 的时候，每修改掉一个 bug 并且确认修改了这个 bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。 三提交时注意不要提交本地自动生成的文件 一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交（例如 eclipse 中的.classpath 文件等） 。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。 四不要提交不能通过编译的代码代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。五不要提交自己不明白的代码 代码在提交入 SVN 之后，你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。 六提前协调好项目组成员的工作计划 项目经理应该合理分配工作计划。每个成员在准备开始进行某项功能的修改之前，如果有可能，先跟工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。 七对提交的信息采用明晰的标注（写注释） 在一个项目组中使用 SVN，如果提交空的标注或者不确切的标注将会让项目组中其他的成员感到很无奈，项目经理无法很清晰的掌握工作进度，无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以，在提交工作时，要填写明晰的标注，能够概要的描述所提交文件的信息，让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。 八慎用锁定功能 在项目中要慎用锁定的功能，在你锁定了一个文件之后别人就无法继续修改提交该文件，虽然可以减少冲突的发生率，但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件（例如图片文件，flash 文件等）时，才适当的采用锁定操作。 篇三：开发部 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. 不要提交不能通过编译的代码。代码在提交之前，首先要确认自己能够在本地编译