分支定位合并方向部署环境
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分支应删除
网友评论