SVN提交代码需要注意的地方



一、提交之前先更新

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

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

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

 

二、保持原子性的提交

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

 

三、提交时注意不要提交本地自动生成的文件

一般配置管理员都会将项目中一些自动生成的文件或者与本地配置环境有关的文件屏蔽提交。如果项目中没有进行这方面的配置来强行禁止提交这样的文件，请自觉不要提交这样的文件。提交了这样的文件后，别人在更新后就可能与本地的环境冲突从而影响大家的工作。

 

四．不要提交不能通过编译的代码

代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库。项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。

 

 

五、不要提交自己不明白的代码

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

 

六、对提交的信息采用明晰的标注

1、像“修复(Fixes)”、“提交(Commit)”这样的提交信息没包含任何有用的信息。如果别人想看看版本历史，像这样的提交信息只会逼他们去看完所有的代码修改，看代码是很费时费力的。写这样一个简短但表达不清晰的提交信息，可能是省了你一分钟时间，但是却浪费了其他人几个小时。

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

2、一个好的提交信息可以让看的人清楚代码的哪一部分被修改了，是怎么被修改的，他们也不需要去看你的代码

 

七、注释说明为什么做这个修改

1、假设每次修改代码都有一个很好的理由/原因，但如果这个理由/原因被没有记录下来，那么整个代码库(codebase)将面临以下风险：

   (1)、其他开发者不明白为什么原代码是那样写的。当他们修改代码的时候，他们可能会引入一些原作者已经发现或者避免的问题。

   (2)、其他开发者认为原代码那样写肯定是有（好的）原因的，所以最好别动它。他们把这些代码看成是一个黑盒，然后加各种复杂的 workaround，避免修改原代码。最后导致这个代码库变得臃肿，代码变得难以看懂。

2、如果你有足够的理由有必要破坏一个项目的规范或者约定，那一定要把这个理由作为注释写在你的代码里面。

3、如果你的代码遵守了规范，并且你的代码没有什么微妙(subtleties)的点需要注意，那就没有必要把你的文档注释写在代码里面。但仍然有必要让人知道为什么新代码优于旧代码（尤其是当新代码引入了一个新问题），所以还是要把原因写在提交信息里面的

参考资料：  SVN提交代码需要注意哪些   http://www.studyofnet.com/news/873.html