一、Git规范
1. 分支管理
git flow流程：
| 分支类型 | 命名 | 分支名称 | 含义 |
|---|---|---|---|
<master> | master | 主分支 | master分支唯一且稳定，一般release分支和fixbug分支修复bug后，确保稳定才合并到master分支 |
<dev> | dev | 开发分支 | dev分支唯一，feature分支开发依赖于dev分支，新建和合并特性分支都是基于dev分支，建议从feature分支开发再合并到develop分支，而非直接在dev分支上开发 |
<release> | release | 预发布分支 | release分支属于发布版本的分支，在同一时间只有一个release分支存在，release分支上只能做一些bug修复，尽量避免大量修改代码 |
<feature> | feat_分支名_命名 | 功能分支 | feature分支依赖于develop分支，可同时存在多个，在每个分支里写代码业务逻辑，完成之后合并到develop分支；分支名可按模块划分，命名可按模块下的组件命名 |
<fixbug> | fix_分支名_命名 | 修补分支 | fixbug分支是基于master分支的，出现bug修复完成后合并回master分支；分支名可按页面划分，命名可按具体位置命名 |
<demo> | demo_分支名_命名 | 演示分支 | demo分支是基于dev分支的，出现和dev分支分歧的部分会单独基于demo新建新的feature分支，完成后进行合并 |
master 分支
- master 为主分支，也是用于部署生产环境的分支，确保master分支稳定性
- master 分支一般由develop以及hotfix分支合并，任何时间都不能直接修改代码
dev 分支
- dev 为开发分支，始终保持最新完成以及bug修复后的代码
- 一般开发的新功能时，feature分支都是基于dev分支下创建的
feature 分支
- 开发新功能时，以develop为基础创建feature分支
- 分支命名: feature- 开头的为特性分支， 命名规则: feature-modulea、feature-moduleb
release 分支
- release-x.x.x.x为稳定版本分支，每个迭代版本正式发布后，以当前版本中的master代码中拉出release-x.x.x.x分支代码为版本稳定代码，release分支中的代码不能增删改。
- x.x.x.x：前两位为大版本号当前如：2.0,2.5；第三位为月份版本号，最后一位为小版本号，如线上紧急修复后拉出的稳定版本。
- 4月份稳定版本为：release-2.0.4.x 5月份稳定版本为：release-2.0.5.x 6月份稳定版本为：release-2.0.6.x
hotfix 分支
- 分支命名: hotfix- 开头的为修复分支，它的命名规则与 feature 分支类似
- 线上出现紧急问题时，需要及时修复，以master分支为基线，创建hotfix分支，修复完成后，需要合并到master分支和develop分支
demo 分支
- 分支命名: demo- 开头的为演示版本分支，它的命名规则与 release分支类似，根据上线的版本创建相应的演示版本分支。
- 三月演示版：demo-2.0.3.0 四月演示版：demo-2.0.4.0 五月演示版：demo-2.0.5.0
2. 日志规范
在一个团队协作的项目中，开发人员需要经常提交一些代码去修复bug或者实现新的feature。而项目中的文件和实现什么功能、解决什么问题都会渐渐淡忘，最后需要浪费时间去阅读代码。但是好的日志规范commit messages编写有帮助到我们，它也反映了一个开发人员是否是良好的协作者。
规则：
- feature分支合并进develop时，需要简介feature功能
- release分支合并进master时，需简介版本功能
- hotfix分支合并进master时，需注明修复bug简介
- 分支的commit内容描述一下提交内容
- feature、release、hotfix在用过之后，将远程仓库删除，保持仓库整洁。【酌情定时清理临时分支】