协同开发中SVN的使用建议

协同开发中SVN的使用建议

1.  注意个人账户密码安全

各员工需牢记各自的账户和密码,不得向他人透漏,严禁使用他人账户进行SVN各项操作(主要考虑每个SVN账号的使用者的权限范围问题)。如有忘记,请找SVN管理员进行重置。

2.  先更新(Update),再提交(Commit)

任何提交操作都必须建议在有更新的基础上。所有人都要养成习惯,凡是要提交时先进行一次更新操作。

SVN更新的原则是要随时更新(Update),随时提交(Commit)。当完成了一个小功能,能够编译并且通过自己测试之后,谨慎地提交。

如果在修改的期间别人也更改了SVN的对应文件,那么Commit就可能会失败。如果别人和自己更改的是同一个文件,那么Update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。

在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。这样既能了解别人修改了哪些文件,同时也能避免SVN合并错误导致代码有错。

3.  多提交(Commit)

每次提交的间歇尽可能地短,以几个小时的开发工作为宜。例如在更改界面的时候,可以每完成一个界面的修改或者设计,就提交一次。在开发功能模块的时候,可以每完成一个小细节功能的测试,就提交一次,在修改bug的时候,每修改掉一个bug并且确认修改了这个bug,也就提交一次。我们提倡多提交,也就能多为代码添加上保险。

每天下班前都应当把当天可编译成功的代码提交到SVN服务器。

4.  禁止提交不能通过编译的代码

代码在提交之前,首先要在本地编译通过后才允许提交。不允许提交任何未编译通过的代码。

如功能点较大,不能完全等开发完在提交,可在中途确保无错误、能编译通过的情况下选择是否提交。

5.  注意解决方案或项目工程文件的提交

当在项目中新增或删除了文件(类、图片、样式文件、JS文件等)或文件夹,应同时提交项目文件。

注:在项目中对文件做了新增或删除操作后,注意按“全部保存”按钮,否则你提交的仅是文件,对应的项目文件是未保存的。

6.  文件的重命名。

使用SVN中的Rename功能给文件进行重命名。

7.  每次提交必须书写明晰的注释

在一个项目组中使用SVN,如果提交空的日志或者不确切的日志将会让项目组中其他的成员感到很无奈,项目经理无法很清晰的掌握工作进度,无法清晰的把握此次提交的概要信息。在发现错误后也无法准确的定位引起错误的文件。所以,在提交工作时,要填写明晰的日志,能够概要的描述所提交文件的信息,让项目组其他成员在看到日志后不用详细看代码就能了解你所做的修改。

8.  提交时不要提交本地自动生成的文件

例如各项目的.user或项目编译生成的临时文件Bin、obj等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件,请自觉不要提交这样的文件。提交了这样的文件后,别人在更新后就可能与本地的环境冲突从而影响大家的工作。

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

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

10.    慎用锁定功能

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

11.    禁止拷贝文件夹

凡是加入代码版本控制的文件夹都会有一个隐藏的.svn文件夹,该目录保存着文件的版本信息,如果未删除该目录,提交时会更新被拷贝的文件夹。若需要拷贝文件夹,请使用SVN的Export功能。

上一篇:Eclipse下Tomcat常用设置


下一篇:分布式微服务架构(一)