分支模型

分支定位合并方向部署环境

master主分支，对应线上的版本接收来自hotfix/poc分支的合并，只接受稳定版本的合并RC环境、生产环境、生产镜像环境

hotfix热补分支，用于修复线上缺陷，命名为hotfix/日期由线上程序对应的代码打出，修复完成后，应合并到master、develop分支生产镜像环境验证通过后，部署到生产环境

pocpoc验证阶段创建的分支提测分支测试通过后，合并到poc验证分支，poc验证通过后，修改内容合并到develop分支，并合并到master分支RC环境（poc验证）

release提测分支，命名规则release/日期从develop分支创建，完成集成后，自测通过的，创建提测分支，测试通过后，合并到poc分支测试环境(test)

develop持续集成分支接受来自feature分支的合并，在feature开发的成果持续集成到develop分支，功能简单的代码库可直接在develop分支开发开发集成环境（dev)

feature新功能开发，命名规则feature/功能名从develop分支创建，新功能在feature开发，持续向develop分支合并相对稳定的成果，功能简单的代码库可不使用feature分支不部署，仅在开发人员本地执行

场景1：新功能开发

由develop分支创建feature分支；

日常在feature开发，阶段成果合并到develop分支（鼓励多个feature分支合并到develop分支），develop分支持续部署到dev环境；

提测前，将feature合并到develop分支，完成自行集成测试；

自测通过后，合并develop分支到release分支，部署到测试环境；

测试通过后，合并release到poc分支，部署到RC环境进行POC验证；

POC验证通过后，由POC分支合并到master分支；

合并后的分支，部署到RC环境、生产镜像环境，验证OK后部署至生产环境。

场景2：修复线上缺陷

在CI找出master分支中对于线上部署版本的点，可能出现master领先于线上部署版本的情况；

从master分支中对应线上部署的点创建hotfix分支；

在hotfix完成缺陷修复，鼓励在一个hotfix分支中修复多个缺陷；

根据master分支是否领先于线上部署版本确定动作：

如master分支领先于线上部署版本，直接部署hotfix分支，先到生产镜像环境，验证通过后，部署到生产环境；

如master分支与线上版本部署版本同步，合并hotfix分支到master分支，部署master分支，先到生产镜像环境，验证通过后，部署到生产环境；

完成修复并验证通过后，合并hotfix分支到master、develop分支；

hotfix是临时分支，合并后，hotfix分支应删除