一、分支与角色说明
Git 分支类型
master 分支（主分支） 稳定版本
develop 分支（开发分支） 最新版本
release 分支（发布分支） 发布新版本
hotfix 分支（热修复分支） 修复线上Bug
feature 分支（特性分支） 实现新特性
Gitlab 角色与项目角色对应关系
Owner（拥有者） Git 管理员
Master（管理员） 开发主管
Developer（开发者） 开发人员
Reporter（报告者） 测试人员
Guest（观察者） 其他人员
二、分支简明使用流程
每开发一个新功能，创建一个 feature 分支，从当前的 master 分支上拉取，多人在此分支上开发。
提测时，将 master 分支和需要提测的分支汇总到一个 release 分支，发布测试环境。
发现bug时，在 feature 分支上debug后，再次回到2。
发布生产环境后，将 release 分支合并到 master 分支，删除 release 分支。
三、创建新项目（master分支）
开发主管提交代码初始版本到 master 分支，并推送至Gitlab系统
开发主管在 Gitlab 系统中设置master 分支为 Protectd 分支（保护分支）
Protected 分支不允许 Developer 角色推送代码，但 Master 角色可以推送代码
四、进行项目开发（develop分支）
开发主管在 master 分支上创建 develop 分支（开发分支），并推送至Gitlab系统
master 分支与 develop 分支一样，有且仅有一个
对于非并行项目可以使用 develop 分支开发方式，对于多人并行开发项目，使用 feature 分支开发方式，但 develop 和 feature 开发方式不应同时使用 (注意：目前项目暂时使用 feature 分支开发方式)
五、开发新特性（feature分支）
每个新需求或新的研究创建一个 feature 分支
命名规范：feature/分支创建日期-新特性关键字，例如：feature/20181220-catering
推荐使用 feature 分支，但 feature 分支的生命周期不能跨一次迭代
六、发布测试环境（release分支）
开发负责人需完成以下任务：
确认要发布的feature 分支上的功能是否开发完毕并提交
创建release 分支（发布分支），将所有要发布的分支逐个合并到release分支，有如下情况：
命名规则：release/分支创建日期-新特性和待发布版本号，例如：release/20181220-餐饮管理v1.0.0，版本可根据需要添加
删除本次发布的所有 feature 分支
发布到测试环境，通知测试
七、修复待发布版本中的Bug（feature分支）
如果发现bug，开发人员在 feature 分支上修复测试人员提交给自己的bug，修复完成后，由负责人再次创建 release 分支，发布测试环境。
八、发布正式环境
开发负责人需完成以下任务：
根据修复后的 release 分支再次将 master 合并，打包发布生产环境
确认发布成功，并线上验收通过后，将 release 分支合并到 master 分支
在 master 分支上创建标签，命名规则：tag/日期-新特性和版本号，例如：tag/20181220-cateringv1.0.0，版本可根据需要添加，作为发版里程碑标记
删除对应 release 分支
九、修复线上Bug（hotfix分支）
线上的不同版本出现了bug怎么办？开发负责人需完成以下任务：
从 master 分支某个 tag 上创建一个 hotfix 分支（热修复分支），一般是最新的 tag 应该和当前生产环境对应
- 命名规则：
hotfix/分支创建日期-bug名称和待发布版本号，例如：hotfix/20181220-仓库添加新字段v1.0.1
开发人员完成Bug 修复，提交 hotfix 分支到测试环境验收通过
再次发布正式环境流程
将 hotfix 分支合并到 master 分支
在 master 分支上创建标签
- 命名规则：
tag/日期-新特性和版本号，例如：tag/20181220-cateringv1.0.0，版本可根据需要添加，作为发版里程碑标记
删除 hotfix 分支
十、Git 的特别注意事项
参考文档：
Git分支管理规范
阮一峰-Git分支管理策略（带git命令）
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
