iOS Development Guidelines
  • Introduction
  • 规范
    • 0. 介绍
    • 1. 序言
    • 2. 代码命名规范
      • 2.1. 代码命名基础
      • 2.2. 方法(Method)命名
      • 2.3. 函数(Function)命名
      • 2.4. 属性(Property)与数据类型命名
      • 2.5. 其它命名规范
      • 2.6. 可接受缩略名
    • 3. 代码格式规范
      • 3.1. 代码注释格式
      • 3.2. 代码结构与排版
    • 4. 开发实践
      • 4.1. Objective-C保留字
    • 5. Xcode工程结构
    • 6. 版本控制
      • 6.1. Git基本配置
      • 6.2. Git分支模型
      • 6.3. SVN源代码管理规范
      • 6.4. SVN的标准目录结构
    • 7. 附录
      • 7.1. Xcode扩展插件
      • 7.2. 第三方开源库
    • 8. 参考
    • 9. iOS开发优化
  • Swift编码规范
  • Objective-C新特性
  • iOS生命周期
  • Apple 官方设计指南
    • iOS 人机交互指南
      • 概览 - 设计理念
      • 概览 - iOS 10 新功能
      • 概览 - 接口要素
      • 交互 - 3D Touch
      • 交互 - 辅助功能
      • 交互 - 音频
      • 交互 - 身份验证
      • 交互 - 数据输入
      • 交互 - 反馈
      • 交互 - 文件处理
      • 交互 - 初次启动体验
      • 交互 - 手势
      • 交互 - 加载
      • 交互 - 模态
      • 交互 - 导航
      • 交互 - 评分和评论
      • 交互 - 请求权限
      • 交互 - 设置
      • 交互 - 术语
      • 交互 - 撤销与重做
      • 系统功能 - 多任务
      • 系统功能 - 通知
      • 系统功能 - 打印
      • 系统功能 - 快速预览
      • 系统功能 - Siri
      • 系统功能 - TV 供应商
      • 可视化设计 - 动画
      • 可视化设计 - 品牌化
      • 可视化设计 - 颜色
      • 可视化设计 - 布局
      • 图像 - 应用图标
  • Apple 官方开发指南
    • App 发布指南
      • 待完善
    • Cocoa 代码指南
      • 代码命名基础
      • 方法命名
      • 函数命名
      • 属性和数据类型命名
      • 可接受的缩写词和首字母缩写词
      • 针对框架开发者的技术细节
    • 核心蓝牙编程指南
      • 待完善
  • iOS 杂谈
    • Auto Layout 是怎么进行自动布局的性能如何
    • App 启动速度的优化与监控
    • 多人的大项目,架构怎么设计更合理
    • 链接器:符号是怎么绑定到地址上的
    • App 如何通过注入动态库的方式实现极速编译调试
    • 静态分析工具的选择
    • Clang的App 提质
    • 无侵入的埋点方案如何实现
    • 包大小:如何从资源和代码层面实现全方位瘦身
    • iOS 崩溃千奇百怪如何全面监控
    • 如何利用 RunLoop 原理去监控卡顿
    • 临近 OOM,如何获取详细内存分配信息,分析内存问题
    • 日志监控:怎样获取 App 中的全量日志
    • 性能监控:衡量 App 质量的那把尺
    • 远超想象的多线程的那些坑
    • 怎么减少 App 电量消耗
    • 除了 Cocoa,iOS还可以用哪些 GUI 框架开发
    • 细说 iOS 响应式框架变迁,哪些思想可以为我所用
    • 如何构造酷炫的物理效果和过场动画效果
    • A/B 测试:验证决策效果的利器
    • 怎样构建底层的发布和订阅事件总线
    • 如何提高 JSON 解析的性能
    • 如何用 Flexbox 思路开发?跟自动布局比,Flexbox 好在哪
    • 怎么应对各种富文本表现需求
    • 如何在 iOS 中进行面向测试驱动开发和面向行为驱动开发
    • 如何制定一套适合自己团队的 iOS 编码规范
    • iOS 系统内核 XNU:App 如何加载
    • iOS 黑魔法 Runtime Method Swizzling 背后的原理
    • libffi:动态调用和定义 C 函数
    • iOS 是怎么管理内存的
    • 如何编写 Clang 插件
    • 打通前端与原生的桥梁:JavaScriptCore 能干哪些事情
    • React Native、Flutter 等,这些跨端方案怎么选
    • 原生布局转到前端布局,开发思路有哪些转变
    • iOS原生、大前端和Flutter分别是怎么渲染的
    • 剖析使 App 具有动态化和热更新能力的方案
  • Flutter
    • 0.Flutter学习笔记以及问题记录
    • 1.Dart基础快速入门
    • 2.什么是声明式UI
    • 3.Flutter入门基础知识
    • 4.项目结构、资源、依赖和本地化
    • 6.布局与列表
    • 7.状态管理
    • 8.路由与导航
    • 9.手势检测及触摸事件处理
    • 9.线程和异步UI
    • 10.主题和文字处理
    • 11.表单输入与富文本
    • 12.调用硬件、第三方服务以及平台交互、通知
    • 13.基于Http实现网络操作
    • 14.图片控件开发详解
    • 15.异步:Future与FutureBuilder实用技巧
    • 16.APP首页框架搭建-Scaffold与PageView
Powered by GitBook
On this page
  • 1. SVN 版本库结构构建
  • 1.1 Trunk
  • 1.2 Branches
  • 1.3 Tags
  • 2. SVN使用规范

Was this helpful?

  1. 规范
  2. 6. 版本控制

6.3. SVN源代码管理规范

1. SVN 版本库结构构建

在大多数人眼中的Subversion,就是那个在代码里被叫做“Trunk”的东西。其实Subversion包含了更多的内容! 为了让你能够更加充分体会到Subversion的好处,本文将讨论如何搭建你的版本库结构。 正如你之前在Subversion的相关文章中看到的那样,Subversion最基本的结构由三个路径组成:branches,tag和trunk。

每个路径在Subversion里都可以单独签出。

1.1 Trunk

任何时候Trunk里包含的都是最新的开发代码。 这里的代码将会工作到你的下一个主要发布版本。

据我所见,几乎常常人们只使用trunk来存放他们的代码。发放了一个版本后继续在其上进行下一版开发。这不好,无论是对你还是你的产品。

Trunk应该只被用来开发将会成为你的下一个重要版本的代码。 不要给trunk加上版本号和发布名称。 仅需要保证trunk在任何时候都处于“开发模式”。

例子:

https://svn.example.com/svnroot/project/trunk

1.2 Branches

这里有几种不同类型的分支。这里我会告诉你一些常见的类型。在branches的目录里,你可以为更多具体的目标创建路径,像即将发行版本。 正如我的文章“article on releasing software from Subversion”里讨论的那样,brahches路径包含了trunk在不同发展阶段的副本。

1.2.1 Release Branches

我们已经见过了 RB-x.x release branches。当trunk达到准备发布的阶段时(或者你想冻结新特色的添加时),你应该创建一个release branches。 Release branches只是你当前trunk的一个副本。

这个branches可以被单独的签出你也可以启动branches和基于此版本的项目。你还可以使用此分支在测试期间修复Bug。 这种方式能够保证trunk继续开发,而不会被发布某个具体的版本所干扰。 因此当你准备发布一个新版本时,这样不会影响你trunk增加新的功能。

1.2.2 Bug fix branches

分支也可以用于处理trunk或release branches里发现的严重的Bug。这些Bug很复杂,你不能在一次提交时就修复他们。因此为了集中精力修正此错误,你应该为此问题创建一个新的分支。这样就不会影响trunk 和 release branches的继续进行,并且你也不会因为发现新的Bug 和测试而干扰此Bug 的修复。

Bug 修复分支的命名通常遵循下列方式:使用你的缺陷管理系统分配给此Bug的ID。通常这是一个数字。如:Bug-3391。

当然,你也可以象其它分支一样访问你的Bug分支。

1.2.3 Experimental branches

有时你想将某个新技术引进项目。这很好,但是你当然不想赌上你的整个项目。想象一下,你想把你的Web程序从PHP4改为PHP5。你要花多少时间?在这期间你的trunk停止使用?直到你把所有到PHP5的转换做完!

这是实验,可能PHP5就像彩虹的另一端一样离你的程序太远了,你应该给他创建一个分支。 你可以在分支里进行更改,如果失败了,你在当前分支仍然有PHP4的代码。

推荐:SVN源代码管理心得

[负责而谨慎地提交自己的代码(先更新后提交)SVN更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且并且自己测试之后,谨慎地提交。如果提交过程中

如果失败了,实验分支可以抛弃。 如果成功,你可以很容易的将其合并到trunk并继续你的新技术。 实验分支命名遵循在面原则:为其名字加上前缀“TRY-”。

1.3 Tags

标签就像分支一样备份你的代码。 但是 Tag不被用来开发,他们只是用来标记你代码的状态。

1.3.1 Release tags

Release Tags 标记你版本发布点的代码。 Release Tag 永远是相应发布分支的副本。 Release Tag命名规则:“REL-”前缀加上版本号。

1.3.2 Bug fix PRE and POST tags

当你创建了一个Bug fix分支,你想标记代码在BugFix之前和之后的状态。 这样你就很容易的引用你所做的更改,合并到trunk或Release branches。

命名规则:   “PRE-”加上Bug ID;

“POST-”加上Bug ID。

2. SVN使用规范

  • 先更新,再提交

    SVN更新的原则是要随时更新,随时提交。当完成了一个小功能,能够通过编译并且自己测试之后,谨慎地提交。 如果在修改的期间别人也更改了svn的对应文件,那么commit就可能会失败。如果别人和自 己更改的是同一个文件,那么update时会自动进行合并,如果修改的是同一行,那么合并时会产生冲突,这种情况就需要同之前的开发人员联系,两个人一起协商解决冲突,解决冲突之后,需要两人一起测试保证解决冲突之后,程序不会影响其他功能。 在更新时注意所更新文件的列表,如果提交过程中产生了更新,则也是需要重新编译并且完成自己的一些必要测试,再进行提交。这样既能了解别人修改了哪些文件,同时也能避免SVN合并错误导致代码有错。

  • 多提交

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

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

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

  • 每次提交必须书写明晰的标注

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

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

    例如eclipse中的.classpath文件,Windows生成的缩略图Thumbs.db,项目编译生成的临时文件.obj, .class等等。如果项目中没有进行这方面的配置来强行禁止提交这样的文件,请自觉不要提交这样的文件。提交了这样的文件后,别人在更新后就可能与本地的环境冲突从而影响大家的工作。

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

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

  • 慎用锁定功能

    在项目中要慎用锁定的功能,在你锁定了一个文件之后别人就无法继续修改提交该文件,虽然可以减少冲突的发生率,但是可能会影响项目组中其他人员的工作。平时只有在编辑那些无法合并的文件(例如图片文件,flash文件等)时,才适当的采用锁定操作。

Previous6.2. Git分支模型Next6.4. SVN的标准目录结构

Last updated 5 years ago

Was this helpful?