分支管理规范

snail-job采用AoneFlow模式分支代码管理规范。

AoneFlow模式组成

一个主干分支+N个特性分支+N个发布分支

使用流程

1. 新需求均从master主干分支拉取一个特性分支；
   
2. 测试分支也从主干分支拉取出去，然后将一个或多个特性分支合并至测试分支；
3. 预发布分支也从主干分支拉取出去，将测试通过后的一个或多个特性分支合并至该分支；
   
4. 成功发布后，发布分支的代码合并到主干分支上。并且每次合并到主干分支时要打上tag，做好记录。最后把发布分支上关联的特性分支删除。
   
5. 所有的修改都不允许直接提交到主干。

Git上的分支命名规范

• master: 主分支，永远是可用的、稳定的、可直接发布的版本，不能直接在该分支上开发;
• develop: 功能开发分支，在master上创建分支，功能测试正常后合并到release分支。命名规则：dev_日期_开发功能模块命名，如：dev_20181220_refund;
• test：测试分支，在master上创建的分支，由各个develop分支合并而成，用于相应功能的测试；每次提测前，删除上一次的test分支，重新创建test分支。
• release：预分布分支，在master上创建，由测试通过后的各个develop分支合并而成，发布确定稳定之后合并到master分支，并在master分支上打上tag，删除相应的develop分支。命名规则：release_版本号，如：release_v1.0.1;
• hotfix: 紧急bug修改分支，项目上线之后可以会遇到一些环境问题需要紧急修复，在master分支上创建，流程跟release分支相似，修复完成后合并到master分支。命名规则：hotfix_版本号。若有历史版本Bug需要修复，在主干分支找到版本标签位置，然后从那个位置创建 Hotfix 分支。

注意事项

• 一个分支尽量开发一个功能模块，不要多个功能模块在一个分支上开发。
• 开发过程中，如果组员A开发的功能依赖组员B正在开发的功能，可以待组员B开发好相关功能之后，组员A直接pull组员B的分支下来开发，不需要先将组员B的分支 merge 到develop分支。