SVN使用规范

SVN使用规范

1.提交必须写明注释

清晰的提交注释有助于别人理解你所做的修改,出现问题时能够快速定位,也有助于项目经理把握开发进度。所以,在提交代码时,要填写明晰的标注,能够概要的描述所提交文件的信息,让项目组其他成员在看到标注后不用详细看代码就能了解你所做的修改。

 

2.禁止提交未编译通过的代码

代码在提交之前,首先要确认自己能够在本地编译,保证主干永远是畅通的。如果引用了新的文件,要确保所用引用的文件一起提交。

l  代码通过单元测试

l  程序启动正常

 

3.不要提交自己不明白的代码

代码在提交入SVN之后,这样代码将被项目成员所分享。如果提交了自己不明白的代码,你看不懂,别人也看不懂,这将会成为项目质量的隐患。因此在引入任何第三方代码之前,确保你对这个代码有一个很清晰的了解。

 

3.不要提交自己的临时测试代码

提交到SVN的代码是比较正式的代码,和其他成员共享,自己的临时测试代码提交前要注释掉,做到不影响其他成员的开发。

 

4.不要提交本地自动生成文件

开发工具会自动生成一些工程等文件,以及项目编译生成的临时文件等等。提交了这样的文件后,别人在更新后就可能与本地的环境冲突从而影响大家的工作。

由于SVN是在公网上,所以上传这些文件会过于累赘,影响提交及其他成员更新源码的速度,也白白浪费SVN服务器的空间资源。

 

5.按功能模块整体提交,提交不要过于频繁

完成一个功能模块后,将该模块相关修改作为整体提交。不宜分离过于频繁提交,导致功能上不同步。

 

6.提交前,先更新再提交

在提交之前先做一次更新操作,这样可以有效防止本地修改的文件产生冲突。

另一个可能就是提交成功了,但会覆盖了前一次其他成员的提交数据。

 

7.提交后可以就近让方便的同事及时更新

让同事及时更新下来,把代码编译一次,确保程序跑起来。

如果有问题,及时修正缺失遗漏的文件,及修正错误,避免错误造成太大的影响。

 

8.慎用锁定功能

在项目中要慎用锁定的功能,在你锁定了一个文件之后别人就无法继续修改提交该文件,虽然可以减少冲突的发生率,但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件时(非文本文件),才适当的采用锁定操作。


[本地工作区] :work copy ,本地工作副本; [主项目]:引用共用模块的新项目(工程) 最新版本(HEAD revision):版本库里文件或目录的最新版本 SA :SVN服务器的管理员 PRA :单个项目库的管理员,或者是项目负责人 User :普通工作人员 WC :work copy ,本地工作副本 1. 版本控制原则 SVN(或者其他版本控制软件)只是一个版本控制的辅助工具,不可能把所有的问题都自动解决掉。尤其,对于冲突这个麻烦事儿,项目成员在项目进程中要尽量通过优化流程来解决,而不是将希望寄托于软件工具来自动解决一切问题。 建议的开发过程组织: 1. 随行就市 项目刚开始阶段,单独开发;项目稳定阶段,完整开发。项目开发初期,各个项目成员负责自己的文件夹(或者模块),与SVN服务器间的更新、提交等操作只需要针对自己负责的文件夹(或者模块)就行了,他人的文件夹(或者模块)可以不必关心;项目稳定阶段,也就是每天的变更量很小了,所有项目成员与SVN服务器的更新、提交等操作需要针对项目的所有文件夹(或者模块),各个项目成员在其本地编译时本地工作区的全部项目程序(或者资料)均为最新的版本,保证项目作为整体能够顺利运行。 2. 能躲就躲 尽量保证一份文件只有一个项目成员在编辑。举例说明:程序员A负责底层中文件 DBAccess.cs的编写,如果程序员B的工作要求他为DBAccess.cs增加两个方法,程序员B应该通知程序员A来增加而不是自己增加;如果此时A非常繁忙需要B自己增加,就需要B先更新本地的DBAccess.cs,然后开始修改,修改完成后立即提交并通知A更新本地的文件,通过缩短提交间隔来减少冲突。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值