SVN提交更新的一个准则

查阅了一下网络和博客园，发现还没有一个明确地指导源码管理提交准则的相关文章，因此斗胆整理了一部分自己平时开发管理的心得，加上查阅了部分英文资料写了一个不算很完善的SVN提交准则。

 

负责而谨慎地提交自己的代码

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

如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。

如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。

 

保持原子性的提交

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

 

不要提交自动生成的文件

Visual Studio在生成过程中会产生很多自动文件，如.suo等配置文件，Debug,Release,Obj等编译文件，以及其他的一些自动生成，同编译代码无关的文件，这些文件在提交的时候不应该签入，如果不小心签入了，需要使用Delete命令从仓库中删除。

 

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

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

 

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

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

 

提前宣布自己的工作计划

在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。

 

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

+) 表示增加了功能

*) 表示对某些功能进行了更改

-) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。

b) 表示修正了具体的某个bug

评论

# re: SVN提交更新的一个准则 [未登录]  回复  更多评论  

2013-02-14 20:50 by Samuel

你在这里说明了SVN提交的一些准则，挺好的。但不完整，SVN提交中最重要的一部分，你遗漏了，就是SVN comment的事情，以及相关的一些准则。
SVN comment规则
[CODE]开头，表示：编码
[BUG]开头，表示：修复BUG
[PM][DOC]开头，表示项目管理文档

等等，你可以定义自己的规则

# re: SVN提交更新的一个准则   回复  更多评论  

2013-02-15 14:51 by Niko7

总结的挺好。以前给新员工培训的时候讲过这个话题，不过没想过要发到网上来，还是你有心。

我总结起来，就是要原子性，独立性，写日志。
就是每次修改肯定有个目的，每次提交的代码应该能完整的达到这个目的，不能把一次修改分成多次提交。这是原子性。在svn里体现为一个变更集。
如果改动比较多，可以分解为解决问题的若干个步骤，那么分批次提交，尽量每个变更集都是目的明确的，不要带有一石多鸟的效果。这是独立性。
做到这两点，日志就很好写，然后把日志写明白。做不到这两点的话，写日志可罗嗦了。

机器生成的代码原则上不提交，但是如果是类库工程，不妨把有里程碑意义的版本的二进制成品在svn里留一份。

关于多久提交一次，我觉得这个就太教条了，有时是几分钟提交一次，有时是几小时提交一次。我觉得不必要求每天下班时要提交。但是上班时要查看更新是必要的。

关于日志，作为一个团队，尽量要用术语和符号，这样可以使日志简洁。