SVN之使用原则

以下是我起草的部门SVN规范里原则的一部分。
  1. 文件提交时要求必须提交注释,注明相关修改信息,例如bug号、任务描述等。具体内容可采用约定或者设置的形式。
  2. 你所提交的改变将体现给其他开发者,要明白提交的后果,提交之前要慎重
  3. 代码变动及时提交,避免丢失本地修改后无法恢复。
  4. 在提交之前要编译代码并修正错误。要保证新增加的文件同时被提交,否则只在你本地能正常工作,导致其它人不能编译通过。
  5. 提交之前要测试所改变的应用,测试改变后的效果是否达到预期的目的。
  6. 多次检查提交的内容。提交之前应先做SVN更新或与资源库同步,注意到SVN关于冲突、错误的信息。资源库同步会告诉你将要提交的内容与资源库内容之间的差别,确认它们是不是你真正想要提交的。
  7. 尊重其他开发者的代码,在重大变更之前与他们协商。SVN并不能替代开发者之间的交流
  8. 提前宣布修改计划。当你计划进行修改,需要影响到SVN里的许多文件时,先通过邮件或者当面通知其他开发者。例如,修改底层数据库模块时,有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备,也会对修改提出意见和建议。
  9. 使用自动提交。SVN一次可以提交多个文件,所以,请一次提交所有相关的文件,即使它们不在目录下。这样可以确保代码在提交前后都是正确的。
  10. 不要将格式修正和代码修正混合提交。修正代码格式包括增加缩进、减少空格等,如果把它们同代码修正一起提交,很难从日志或资源库同步信息里发现代码的修正。所以应该把修正问题与修正格式分开提交。
  11. 每次提交尽量是一个最小粒度的修改。比如一个debug提交一次,一个小功能提交一次。
  12. 每日进行开发工作之前更新代码。避免与昨天其他开发者的代码冲突。
  13. 所有的代码文件编码格式应该是UTF-8的。包括的类型如java, jsp, xml, php, html等。
  14. 提交的文件必须是开发者共用的程序文件,私人测试程序、程序缓存、图片缓存文件不要提交到SVN里。作为一个特例,eclipse的工程配置文件.project可以提交到SVN。一些常见的文件和目录可以加到SVN属性的忽略列表里,包括Thumbs.db、/build/、*.class、/classes/、/data/等等。

[本地工作区] :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更新本地的文件,通过缩短提交间隔来减少冲突。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值