分支管理规范
依据gitflow工作流实行符合目前项目组的git管理规范。
- 背景：基于gitflow工作流，结合目前的版本快速迭代周期，每周1～2个。
- 方案：release和develop合并成一个固定分支，简化快速迭代流程，同时也为了CICD。
- 缺陷：多测试环境不支持。
预发环境上master的原因，是防止release在合并到master的时候，代码遗漏。
功能分支
每个新功能位于一个自己的分支，这样可以push到中央仓库以备份和协作。
但功能分支不是从master分支上拉出新分支，而是使用`release`分支作为父分支。从release上拉出的新分支命名统一以feature作为功能分支，例如：feature/CCC-001。当新功能完成时，合并回release分支。
新功能提交应该从不直接与master分支交互。
测试分支
当快到了既定版本的提测日，所有的功能分支 feature/any 合并到 release 上， release 分支开始作为测试分支，此时`release`不再接受新的功能分支的合并。这个分支上——这个分支只应该做`Bug`修复、文档生成和其它面向发布任务。
release分支上面测出的bug，需要从release分支上拉取新的bugfix/any作为测试修复分支，修复完成之后，合并回 release分支。
发布分支
一旦`release`分支上有了做一次发布（或者说快到了既定的发布日）的足够功能，以及`release`分支上的功能通过测试，就将release分支合并到master分支上进行预发布测试。
`release`合并到`master`上后，`master`开始发布循环，所以从这个时间点开始之后新的功能不能再加到`release`和`master`分支上。
一旦对外发布的工作都完成了，`master`分支并分配一个版本号打好`Tag`。
热修复分支
维护分支或说是热修复（`hotfix`）分支用于生成快速给产品发布版本（`production releases`）打补丁，这是唯一可以直接从`master`分支`fork`出来的分支。
修复完成，修改应该马上合并回`master`分支和`release`分支，`master`分支应该用新的版本号打好`Tag`。
为`Bug`修复使用专门分支，让团队可以处理掉问题而不用打断其它工作或是等待下一个发布循环。
你可以把维护分支想成是一个直接在`master`分支上处理的临时发布。
tag命名规范
格式：v年.月.日
列如：v19.12.24
如果当天有多次合并 master
列如：v19.12.24-01，v19.12.24-02 ...后面的 01 累加
多测试环境补充
日常开发中涉及到项目并行过程，所以考虑多测试环境。目前再申请了一套测试环境。为了兼容测试环境的CICD，考虑到测试分支的固定，所以每个项目再拉一个release分支，命名“release-1”,涉及到中银或者钱包类似的项目，在release-1分支上测试，feature分支也从该release-1分支拉取。