首先，项目有两个长期分支：
有且仅有一个master分支，每个hotfix和release的子分支，在完成发布流程后，都应合并到master分支
每个版本都有一个独立的develop的子分支，每次创建的新的develop子分支都要基于前一个发布版本（hotfix或者release的子分支）
子分支的命名都才用版本累计的方式命名，例如：develop/0.1.0
其次，项目存在三个短期分支：
每个feature子分支都对应一个功能的开发（注意：开发的粒度尽量精细并且各个功能都尽量独立），每个feature子分支的创建都基于当前对应的develop子分支，每个feature子分支开发完成后都应合并到对应的`子分支
用于提测为目的，每个develop的子分支都应有相应的test子分支，每个test子分支的创建都基于develop的子分支，每个test子分支都分别单独提测
当线上发布的版本（release的子分支）出现bug并且急需修复时，需要开出一个hotfix子分支（基于当前的release分支）来修复目前release版本的问题，并且发布该子分支
一旦完成开发，并且发布上线后，就必须要合并到develop或者master
- 当需要合并分支时，将源分支和目标分支都使用git pull拉取到最新的代码，再切换到目标分支，再将源分支进行merge操作
- 每个feature子分支都尽量保持功能的独立以及粒度的精细
- 每次commit的粒度都尽可能保持最小
- 所有分支的命名都尽可能保持统一风格和遵守规范
-
提交代码时，需要控制提交文件的粒度，尽量做到细化粒度，每做一个不同功能的代码修改做一次提交
-
提交代码时，需要在git的信息使用如下规范：
提交代码解决的问题类型（主要分为 修复fix、添加add、修改update、删除delete） + 英文冒号符号（请注意使用英文符号）+ 英文空格 + 解决的问题的描述（内容需要尽可能的详细） + 中文括号描述解决方法（可选）例：
- feat 新特性增加
- fix 修复
- add 新增代码片段或资源
- update 修改
- delete 删除
- chore 构建过程变动、代码
- style 文档格式整理（无代码功能的新增或者减少）
fix: 修复了滚动条无法滚动的问题（由于overflow引起的，现在去掉overflow即可解决）
update: 修改了商品列表中，顶部的信息盒子（.message-box）的高度
delete: 删除了多余的文件
版本格式：主版本号.次版本号.修订号，版本号递增规则如下：
主版本号：当你做了不兼容的 API 修改， 次版本号：当你做了向下兼容的功能性新增， 修订号：当你做了向下兼容的问题修正。
例如：当开发一个完全新功能时，版本号为0.1.0；当开发一个该版本的修复版本时，版本号为0.1.1；当开发和当前版本相比不兼容的API时，版本号为1.1.1。
https://semver.org/lang/zh-CN/ http://www.ruanyifeng.com/blog/2015/12/git-workflow.html