分支管理规范
本篇介绍具体的规范，包括分支的划分和命名规范，不同类型的分支应对不同的场景，然后会介绍下工作 流工具git-flow，如何简化我们的操作。
注意：test和develop（dev）分支 绝对！绝对不允许合并到自己从master拉出的分支上！！！
分支构成
master、test和develop（dev）分支一直存在，且名称不会变化，一般不直接修改这3个分支，由其他分支合并而来。
feature、hotfix分别用于功能点开发、优化，特定版本测试，线上问题紧急处理，同一类型的分支会产生多个。
分支划分如下：
master：与线上版本保持绝对一致；
test：测试分子，由下文提到的feature、hotfix分支合并过后的代码；
develop：开发分支，由下文提到的feature、hotfix分支合并过后的代码；
feature：实际功能点开发分支，建议每项目（一次迭代）新建一个feature，从master创建出来的分支；
hotfix：该分支主要用于修复线上bug；
命名规范约定如下：
feature分支命名：feature/name
hotfix分支命名：hotfix/name
比如有一批新迭代的需求，可在master分支的基础上创建新分支 feature/禅道项目代号_负责人/团队_分支创建日期（YYYYMMDD）_来源分支名称 进行开发，开发完成后合并到develop分支
比如线上有个严重bug需要马上修复，可在master分支的基础上创建新分支 hotfix/禅道BUGID/修复问题_分支创建日期（YYYYMMDD）_来源分支名称 进行开发
分支详细介绍和处理流程
master分支
主分支，与线上运行的版本始终保持一致，任何时候都不要直接修改master分支。
一个版本的feature分支、hotfix分支开发完成后，会合并代码到master分支，也就是说master分支主要来源于feature分支和hotfix分支。
新增功能时基于该分支创建feature分支。
test分支
测试分支，始终保持最新完成以及bug修复后的代码。
一个版本的feature分支、hotfix分支开发完成后，也会合并到test分支，另外，一个版本的feature功能开发完成后，也会合并到develop分支。也就是说test分支来源于feature、hotfix分支。
develop分支
开发分支，始终保持最新完成以及bug修复后的代码。
一个版本的feature分支、hotfix分支开发完成后，也会合并到develop分支，另外，一个版本的feature功能开发完成后，也会合并到develop分支。也就是说develop分支来源于feature、hotfix分支。
feature分支
开发新功能或优化现有功能时，会创建feature分支，以master为基础创建。一般会有多批功能同时开发，但上线时间可能不同，在适当的时候将特定的feature分支合并到develop分支，并合并test分支，进入测试状态。
hotfix分支
线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和test分支。
特殊情况处理和注意点
develop分支已存在未上线的feature代码, 此时需要紧急上线一个新功能, 但develop的代码不能上，如何处理 ？
以master为基线创建feature， 在完成之后，代码合并到master分支；
为了保证develop是最新代码，需要从master合并到develop分支；
以develop为基线，创建了f1和f2两个feature分支之后, f1,f2开发一半的时候，发现两个分支代码需要有依赖怎么办 ？
最好在开发开始前确定两个功能是否相关,若相关则只创建一个分支,两个功能在一起开发;
如果已经创建，则需要合并到一个分支；
一定要保证commit历史记录的整洁，代码合并时，根据情况选择merge或rebase;
使用rebase注意，一旦分支中的提交对象发布到公共仓库，就千万不要对该分支进行衍合操作；
提交说明规范：
提交说明最好限制在一行以内，50个字符以下，简明扼要地描述更新内容，空开一行后，再展开详细注解；
运行环境
开发环境：对应dev分支代码发布构建运行。
测试环境：对应test分支代码发布构建运行。
预发布环境：对应master分支代码构建运行。
正式环境：直接拷贝预 发布环境 代码运行。
发布版本
每次功能发布版本确定成功后，需要在master分支上打tag（标签）。
标签命名规范：feature-v版本号-发布时间（YYYYMMDD）
修复线上问题
线上紧急bug发布完成以后，需要在master分支上打tag（标签）。
标签命名规范：hotfix-v版本号-发布时间（YYYYMMDD）