使用Git.Svn等版本控制系统的提交准则

参考博客: SVN提交更新的一个准则

1. 提交之前先更新
   
   • 基本原则是要随时更新，随时提交 。当完成了一个小功能，能够通过编译并且并且自己测试之后，谨慎地提交。
   • 如果提交过程中产生了冲突，则需要同之前的开发人员联系，两个人一起协商解决冲突，解决冲突之后，需要两人一起测试保证解决冲突之后，程序不会影响其他功能。
   • 如果提交过程中产生了更新，则也是需要重新编译并且完成自己的一些必要测试，再进行提交。
2. 保持原子性的提交
   
   • 每次提交的间歇尽可能地短，以一个小时，两个小时的开发工作为宜 (小步快跑)。
   • 如在更改UI界面的时候，可以每完成一个UI界面的修改或者设计，就提交一次。在开发功能模块的时候，可以每完成一个小细节功能的测试，就提交一次，在修改bug的时候，每修改掉一个bug并且确认修改了这个bug，也就提交一次。我们提倡多提交，也就能多为代码添加上保险。
3. 提交时注意不要提交本地自动生成的文件
   
   • 对于Java来说, IDE自身配置文件, 和字节码文件是无需提交的 例如 .idea目录 iml文件
4. 不要提交不能通过编译的代码
   
   • 代码在提交之前，首先要确认自己能够在本地编译。如果在代码中使用了第三方类库，要考虑到项目组成员中有些成员可能没有安装相应的第三方类库，项目经理在准备项目工作区域的时候，需要考虑到这样的情况，确保开发小组成员在签出代码之后能够在统一的环境中进行编译。
5. 不要提交自己不明白的代码
   
   • 提交之后, 你的代码将被项目成员所分享。如果提交了你不明白的代码，你看不懂，别人也看不懂，如果在以后出现了问题将会成为项目质量的隐患。因此在引入任何第三方代码之前，确保你对这个代码有一个很清晰的了解。
6. 提前协调好项目组成员的工作计划
   
   • 在自己准备开始进行某项功能的修改之前，先给工作小组的成员谈谈自己的修改计划，让大家都能了解你的思想，了解你即将对软件作出的修改，这样能尽可能的减少在开发过程中可能出现的冲突，提高开发效率。同时你也能够在和成员的交流中发现自己之前设计的不足，完善你的设计。
7. 对提交的信息采用明晰的标注
   
   • +) 表示增加了功能
   • *) 表示对某些功能进行了更改
   • -) 表示删除了文件，或者对某些功能进行了裁剪，删除，屏蔽。
   • b) 表示修正了具体的某个bug