svn规范

发表于   |   分类于   |     |   阅读次数

Svn目录规划

svn目录结构如下

最好是一个项目一个Svn库

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Svn库
│-tags(发布)  

│ │-release_1.0(copy from trunk)

│ │-bugfix_release_1.0

│-trunk(主版本)

│ │-项目文件

│-branches(分支)

│ │-bugfix_1.0(copy from tags/release_1.0)
  • 开发完毕，代码冻结，基于已经冻结的trunk，为release_1.0打tag，trunk继续新版本开发。
  • 如果发现1.0有bug，需要修改，则基于release_1.0的tag做branch。
  • 在branch进行bugfix_1.0 bug修复，当bug修复完成基于bugfix_1.0做bugfix_release_1.0。
  • 根据需要选择性的把bugfix_1.0这个分支merge回trunk。

Svn使用规范

日常更新

在Svn的日常更新中做到如下要求：

  • 每日进行开发工作之前必须更新代码，下班时提交代码。
  • 各员工需牢记各自的账户和密码，一定不得向他人透漏，严禁使用他人账户进行Svn各项操作
  • 每次提交必须填写注释，注释不能少于5个中文字符，注释不能毫无意义，要讲明白本次提交的问题。
  • 文件提交前必须先update代码再commit,如果遇到冲突,严禁删除原版本后直接上传新版本
  • 文件提交前必须检查是否有语法错误,php文件要使用php -l [文件名]通过检测
  • 提前宣布修改计划。当你计划进行修改，需要影响到SVN里的许多文件时，先通过邮件或者当面通知其他开发者
    例如，修改底层数据库模块时，有可能影响到业务逻辑层调用数据库模块的地方。这样其他开发者会有准备，也会对修改提出意见和建议
  • 原子性提交代码(即一个小功能提交一次)
  • 禁止使用锁定功能
  • SVN管理员需对SVN的所有项目定期备份

注释提交说明

Svn提交注释填写标识说明：

  • *表示更新功能
  • +表示增加文件或功能
  • -表示删除文件或功能
  • b表示修正了具体的某个bug

在线手册

坚持原创技术分享，您的支持将鼓励我继续创作！