My Git Flow

目前需要解决的问题：

1. 一个版本中的多个功能都开发完成后，需要集成测试。
2. 在开发过程中，多个功能分支后台开发完成后，需要给前端提供接口并开发，需要将几个后台功能分支同时部署到开发环境(服务器有限)，并且这几个功能有可能还不同时上线。
3. 多个固定计划的版本在同时开工的情况下，多个计划版本都测试完成后，单只有部分上线，其他的待命。
4. 在稳定迭代开发的同时有紧急bug修复或有紧急需求要开发并上线。
5. 在某个功能上线(master分支)完成后发现有未测试到的点，急需回滚。

解决办法：

1. 每个版本基于 develop 分支创建新分支(如:M9W2)，作为该版本的功能主干分支，该版本的各个功能分支都完成后，在合并回功能主干分支，然后基于该功能主干分支迭代修改，直到测试通过。
2. 利用临时分支 dev-merge 合并开发中的多个feature分支，然后部署到开发环境。
3. 每个功能主干分支测试完成后，先不提交到develop，在需要上线的时候再pull develop分支，如果与其他版本有代码合并，则再进行一次回归测试，没问题了在 push 到 develop，并打tag，然后提交到master上线。
4. 使用hotfix或feature规范的分支，这种分支有的会merge到master，有的feature是该阶段一次性使用，所以不必merge回master，而是直接部署该分支即可。
5. 如果上线平台有备份每次的上线的包(如：war/jar/docker image)，可以直接恢复该包进行回滚操作；也可以在merge master前将master打个备份tag或分支，如 master/1012，直接部署该分支即可。

分支划分

• master : 主分支，一般都是从该分支部署到线上
• hotfix/* : 修复线上bug分支
• develop : 开发主干分支
• release/* : 发布版本分支
• MxWy：周迭代版本，如M1W2(1月第2周)，固定频率迭代使用
• feature/* : 功能分支，使用在非固定频率迭代开发或固定频率迭代的子任务
• dev-merge/* : (临时分支)开发合并
• dev-qa-merge : (临时分支)开发部分功能测试
• dev : (临时分支)部署分支,部署到开发环境
• test : (临时分支)部署分支,部署到测环境

原理图

最左侧的dev(34)和test(35) 是指部署到某个开发环境34和测试环境35

REF

• A successful Git branching model
• 如何正确使用Git Flow
• 基于git的源代码管理模型——git flow