BONESDAO 代码提交规范
本文是 BONESDAO 代码提交 & 版本控制规范，代码库基于 Git 管理。
分支模式
代码库采用分支模式管理，其中主要分支如下：
- master
- develop
- featrue/xxxx
- hotfix
两个主分支在仓库中：
master
产品主干代码，维护一个稳定的对外代码库，不能直接工作在这个 master 分支上，而是在其他指定的，独立的特性分支中（这方面我们会马上谈到）。不直接提交改动到 master 分支上也是很多工作流程的一个共同的规则。
develop
开发分支，是你进行任何新的开发的基础分支。当你开始一个新的功能分支时，它将是开发的基础。另外，该分支也汇集所有已经完成的功能，并等待被整合到 master 分支中。
这两个分支被称作为 长期分支。它们会存活在项目的整个生命周期中。而其他的分支，例如针对功能的分支，针对发行的分支，仅仅只是临时存在的。它们是根据需要来创建的，当它们完成了自己的任务之后就会被删除掉。
featrue
feature用于功能开发，功能特性
功能开发
功能开发流程如下：
-
开始新功能
每次开始一个新的功能，从develop拉一个feature/xxx分支，功能完成后merge回develop
-
功能提交
功能开发完成后，开发者提一个pull request，等待代码审核，代码审核通过后merge到develop分支，并删除feature/xxx分支。
管理 releases
Release 管理是版本控制处理中的另外一个非常重要的话题。
创建 release
当你认为现在在 “develop” 分支的代码已经是一个成熟的 release 版本时，这意味着：第一，它包括所有新的功能和必要的修复；第二，它已经被彻底的测试过了。如果上述两点都满足，那就是时候开始生成一个新的 release 了：
- 把develop分支merge到master
- 从当前master打一个Tag，并发行响应的release版本
hotfix
很多时候，仅仅在几个小时或几天之后，当对 release 版本作做全面测试时，可能就会发现一些小错误。
这种情况下我们需要创建 hotfix 分支：
- 从主干拉取hotfix分支进行修复
- 提一个pull request 等待代码审核
- 审核过后，merge 到 master 和 develop 分支