一、分支规范及命名
首先，项目存在两个长期分支。
- 主分支 - master
- 开发分支 - develop
前者用于存放对外发布的版本，任何时候在这个分支拿到的，都是稳定的发布版；后者用于日常开发，存放最新的开发版。
其次，项目存在以下三种短期分支：
-
特性分支 - feature
命名规则：feature/<任务名> 如：feature/Sonar -
里程碑功能分支
确定了里程碑后，即可将分支移到当前里程碑下面。
命名规则：里程碑/<任务名_redmine单号> 如：里程碑0711 的 #123456 xxx需求，分支名可定为 0711/xxx_123456 -
里程碑主分支
里程碑上的各个功能分支测试通过后，可合并到里程碑主分支上，方便QA进行回归测试。
命名规则：里程碑/dev 如：0711/dev
注意：
有确定里程碑的需求/Bug分支，可在该里程碑下建分支（如0725/xxxx_123456）；若里程碑下分支确定移出该里程碑，建议移入新的里程碑或feature、bugfix下。详见以下流程规范说明。
二、流程规范
I. 分支规范
- 特性分支
创建：当需要开发某个比较大的功能（这个标准由开发人员自己根据具体情况进行判断），且上线版本未确定时，创建 feature 分支。
合并：确定里程碑后，移入里程碑下。
注意：
如果开发期间有版本上线，应在上线后把 develop 分支的代码合并（merge）到特性分支上来。
- 里程碑功能分支
创建：确定了里程碑的代码改动
合并：测试通过后，合并到里程碑主分支上。
注意：
如果合并到里程碑主分支时机较早，存在该需求被移出该里程碑的可能时，须在功能分支修复bug，确保功能分支的完整性。
如果开发期间有版本上线，应在上线后把 develop 分支的代码合并（merge）到功能分支上来。
- 里程碑主分支
创建：当一个里程碑开发工作开始时，即可从 develop 分支创建里程碑主分支。
合并：该里程碑的代码回归测试通过，合并到 develop 分支上。
注意：
1、如果开发期间有版本上线，应在上线后把 develop 分支的代码合并（merge）上来；
2、建立周版本分支之后，修改提升应用版本号。举例如v6.5.0已定版/发布，新建的周版本分支（0725/dev）可修改版本号为v6.6.0（此时build号为单数）。
- 开发分支
合并：当里程碑主分支回归测试通过后，合并到 develop 上来；
在发布前，把内部版本号改为双数，把 develop 分支合并到 master 上去。
注意：
合并完成后，把develop分支内部版本号改回单数
- 主分支
注意：
master 分支必须严格遵守只进不出的原则，只能从 master 分支拉分支出来，开发完成后合并回去，不能在 master 分支上进行任何代码修改提交。
master 分支的内部版本号永远都是双数。
II. 上线规范
1、打标签 —— 审核通过后，在 master 分支上创建标签。
2、更新各分支 —— 审核通过后，把 develop 分支的代码合并到各个短期分支上。
3、清理分支 —— 对已上线的短期分支进行清理。
三、标签
-
标签类型
Git 标签分为两种类型：轻量标签和附注标签。轻量标签是指向提交对象的引用，附注标签则是仓库中的一个独立对象。我们统一使用附注标签。 -
命名规则
标签名为 x.x.x，注意不含"v"。附注信息为"version x.x.x build xxx"，前面是版本号，后面是内部版本号。譬如以 iOS 版本 3.10的标签为：
标签名：3.10.0
附注信息：version 3.10.0 build 200 -
创建方法
在 Git 中创建一个附注标签是很简单的，只需运行如下命令，此处继续以 iOS v3.10.0 为例：
$ git tag -a 3.10.0 -m "version 3.10.0 build 154"