项目中的基本 git 规范及 swift 编程规范

前两天写了下项目的 REEADME，主要涉及到版本控制、工程目录说明、编程规范三部分。工程目录部分这里就略了，版本控制也是git比较基本的模式。重点是第三部分的编程规范，这部分转自：Swift 4.0 编码规范，持续更新中…（已更新Swift 5.0），整体来说还是比较全面的，大家可以多为原文作者点赞！

目录：

一.版本控制

1. Notice
2. Code review
3. Commit

二.代码规范

1. 编码格式
2. 命名规范
3. 语法规范
4. Swift 4 新特性
5. Swift 5.0 新特性

版本控制

项目采用git-flow模式进行开发, 两个长线分支：master, develop, 其他的都是临时的、短暂的辅助分支. 分支说明如下：

• master 是已经发布上线的内容。
• develop 是进行集成开发的分支, 由 master 分支创建而来
• feature 是针对特定功能进行开发的分支, 由 develop 分支创建而来, 开发完毕后合并至 develop
• release 是开发完毕从 develop 分离, 待发布至生产环境的分支, 发布完毕测试无误合并至 master 和 develop 后删除
• hotfix 是针对线上BUG进行紧急修复的临时分支, 由master 分离解决后合并至 master

Notice

• 开发时应该以 develop 为基础建立功能分支 feature 进行特定功能开发。
• 分支先在本地实施版本控制，然后以同名分支定期向服务器进行 Push。
• 开发结束后向 develop 发送 Merge Request。
• Merge Request 通过代码审查之后才会合并到 develop, 如果审查不通过会被打回重写
• 若非严重功能性BUG, 禁止从Master拉取分支改动代码

Code review

每次提交前务必进行 code review，可借助 sourceTree 之类的工具查看 diff，单个成员时自我审查，多个成员时发起 merge request 由负责人审查。

Commit

• 禁止commit的代码包含 print ，需要打印信息的地方可用项目中已封装的 debugPrint 代替。

• 项目中需要忽略的文件已做处理，后续如有需要忽略的内容，要及时更新到 .gitignore 文件。

• 如非必要, 不推荐使用 git add .&git commit 命令, 所有需要纳入版本控制的文件, 请务必审查。

• 所有 commit 必须写明开发内容, 以前缀区分，具体规则如下

Subject: 1.