1.1.分支说明
Git 的分支主要分为两个长期分支 master 、develop ；三个短期分支hotfix 、release、feature
两个长期分支
-
master分支：主干分支，用于存储正式发布的产品，任何时候在这个分支获取到的都是稳定的已发布的版本，与线上版本同步；master分支只能通过与其他分支合并来更新内容，禁止直接在master分支进行修改
-
develop分支：开发主分支，用于日常开发，包括代码优化、功能性开发等，是进行任何新的开发的基础分支，该分支汇集所有已经完成的功能，通过与其他分支合并来更新内容，并等待被整合到master分支中
三个短期分支
-
feature分支：功能开发分支，可以存在多个，用于开发功能，每一个新的功能可以创建一个新的分支
-
hotfix分支：补丁分支，用来修复生产环境中的紧急bug,每个线上的bug都需要从master分支上创建一个对应的hotfix分支
-
release分支：准备要发布版本的分支，当develop版本的代码处于成熟时，基于develop创建一个release分支
1.2.分支管理
1、master分支
操作要求：该分支只有开发leader具有merge权限，不允许commit/push，仅允许来自 release/、 hotfix/ 分支的合并，每次接受合并后创建TAG
对应环境：生产环境
Tag命名规范：master分支只有1个，名称即为master，代码合并到master需打Tag，示例：vA.B.C：A为大版本号，B为小版本号，C为补丁版本号
生命周期：伴随项目的整个生命周期过程
2、develop分支
操作要求：该分支只有开发leader具有merge权限，不允许commit/push，从master分支克隆，允许来自 feature/ 、release/、hotfix/分支的合并
对应环境：开发环境
Tag命名规范：develop分支只有1个，名称即为develop
生命周期：开始开发后一直存在
3、feature分支
操作要求：允许commit/push，从develop分支克隆, 并在该feature分支上进行开发，功能开发完合并到 develop分支，最后删除该分支
对应环境：本地环境
分支命名规范：feature/vA.B.0/，A为大版本号，B为小版本号，为功能简述，例：feature/v1.0.0/order-detail
生命周期：当前feature开发期间
4、hotfix分支
操作要求：允许commit/push，从master分支克隆，并在该分支上进行bug修复，修复完成后，将hotfix/分支合并到master分支和develop分支，最后删除该hotfix/分支
对应环境：补丁环境
分支命名规范：hotfix/vA.B.C，A为大版本号，B为小版本号，C为补丁版本号，C≠０，例：hotfix/v1.0.1
生命周期：确认要修复Bug到重新发布到master并打tag以及合并到develop分支
5、release分支
操作要求：允许commit/push，当develop分支上的项目准备发布时，从develop分支上创建一个新的release分支，发布任务时，需要将release分支合并到master分支完成发布，然后再将release/分支代码合并到develop分支，以保证代码的一致性，最后删除release分支
对应环境：测试环境
分支命名规范：release/vA.B.0，A为大版本号，B为小版本号，例：release/v1.1.0
生命周期：版本功能开发完到发布并打tag，合并到master及develop分支
1.3. 分支人员权限
1.4 Git flow工作流程
1.4.1 Git flow工作流程-日常开发
1.4.2 流程说明
1.4.2.1 需求开发
（1）开发leader从develop分支创建feature/分支，并按照分支命名规范进行命名，开发人员在对应的feature/分支进行开发；
（2）开发完成后通知开发leader，由开发leader合并代码到develop分支；
（3）开发在develop分支构建代码发布到开发环境进行自测；如果自测不通过，在对应的feature/分支进行修改后再由开发leader合并到develop分支，直到自测通过；
1.4.2.2 需求转测
（1）开发在开发环境集成测试通过后，进行转测代码评审，PM/开发leader需参加；
（2）代码评审通过后，由开发leader从develop分支创建release/分支，并按照分支命名规范进行命名；若评审不通过，由开发做出修改，直到评审通过；
（3）测试在release/分支构建代码发布到测试环境进行测试；
（4）如果测试过程中发现Bug，则由相应开发在release/分支上修复Bug；
（5）开发修复完Bug后，由测试在release/分支进行验证；
1.4.2.3 需求发布
（1）测试人员在release/分支验证通过后的需求，由运维人员将代码合并到master分支，按照规范打上标签进行需求发布；
（2）发布完成后，运维人员将release/分支代码合并到develop分支，然后删除该release/分支；
1.4.3 Git flow工作流程-生产Bug修复
1.4.4 流程说明
（1）生产环境发现Bug需要修复后，由运维人员在master分支上拉取hotfix/分支，并按照分支命名规范进行命名;
（2）相关开发在hotfix/分支提交修复Bug的代码；
（3）开发在hotfix/分支提交完代码后，由测试拉取hotfix/分支构建代码发布到测试环境并进行验证；
（4）验证通过后，由运维人员合并hotfix/分支到master，按照规范打上标签进行补丁发布；
（5）发布完成后，运维人员再将hotfix/代码合并到develop分支，然后删除该hotfix/分支；