分支管理参考git-flow（git-flow介绍）的工作流程，但不使用git-flow。所有的分支的操作都需要手工完成。
1.1、git-flow流程图：
1.2、分支说明：
featrue/XXX: 功能开发分支，继承自master分支，根据需求或者线上bug创建分支，开发、测试阶段所有改动只在该类型分支上修改；
dev: 开发合并分支，合并来自feature/*的分支代码，注意不要在此分支上做修改提交！！！只做合并操作！！！，并在此分支打包提交测试；
master：发布分支，feature/*测试通过的分支，合并到该分支，注意不要在此分支上做修改提交！！！只做合并操作！！！，并在此分支打包发布。
hotfix/XXX: 热修复分支，继承自master分支，仅用于修复master分支上的问题。完成后合并到各分支。
bugfix/XXX: bug修复分支，继承自master分支，仅用于修复master分支上的问题，完成后合并到各分支。
注意：当合并有冲突时，要解决冲突后再提交，避免造成页面奔溃。不熟悉命令合并的同学可以使用编辑器的merge功能，或者可以使用工具，如：sourceTree。
2. commit 规范
一般来说，commit message 应该清晰明了，说明本次提交的目的。我们参考目前比较流行的Angular规范
commit 格式：<type>: <subject>(注意冒号后面有空格)。
（1）type: 用于说明 commit 的类别，无特殊情况下只使用下面7个标识。
- feat：新功能（feature）
- fix：修补bug
- docs：文档（documentation）
- style： 格式（不影响代码运行的变动）
- refactor：重构（即不是新增功能，也不是修改bug的代码变动）
- test：增加测试
- chore：构建过程或辅助工具的变动
（2）subject: commit 目的的简短描述，不超过50个字符。
例：
git commit -m "feat: 新增酒店刷新页面"
git commit -m "fix: 活动中心基本信息页活动ID不可选"
git commit -m "doc: readme文件添加项目打包说明"
注意：如果是有多种形式的修改，以最主要的修改选择type，其他修改可在subject中说明。
3、版本发布规范
已经测试完毕的功能分支合并到master，按版本号打tag。
版本号组成：：v <主版本号>. <子版本号>. <修订号>。
主版本号前加v标识表示version。如初始版本可为v1.0.0或v0.1.0
管理策略：
- 当项目在进行了局部修改或 bug 修正时，主版本号和子版本号都不变，修正版本号加 1。如v0.1.1；
- 当项目在原有的基础上增加了部分功能时，主版本号不变，子版本号加 1，修正版本号复位为 0。如:v0.2.0;
- 当项目在进行了重大修改或局部修正累积较多，而导致项目整体发生全局变化时，主版本号加 1。如：v1.0.0;
版本说明：
每一次版本的发布都需要对该次版本上线进行说明，说明信息参考commit规范：
例：
git tag -a v0.1.0 -m "feat: 初始版本上线，包括首页、列表页、详情页等" master
建议：可在项目中添加版本说明文档，可方便查看生产环境当前版本。
