一、目的
为了减少在团队协作开发时因分支管理不当而出现的代码丢失、错乱情况，需要一套标准规范来约定分支的相关操作；主要针对分支命名规范、分支操作流程进行说明
二、分支命名约定
-
master分支：长期分支，可以随时编译对外发布的稳定版本，不允许直接push 代码，只能进行MR操作；
-
develop 分支：长期分支，这个分支是主开发分支，包含所有要发布到master分支的代码，这个主要合并自其他分支，比如Feature分支。
-
feature分支：短期分支（命名以feature/ 开始），feature 分支主要用来开发一个新的功能，开发完成之后，切到develop分支，再合并刚刚开发的feature分支，若有冲突则解决冲突；Feature分支开发完成可以选择删除或者保留
-
hotfix分支: 短期分支(命名以hotfix/开始)，一般用于修复已发布版本的bug，直接从master上拉取。
三、流程图
这里为了简单起见，没有创建release 分支，采用相对简单的模式。
流程描述：
新功能开发
- 当我们需要开发新功能时，我们从最新的master 分支创建feature/function_desc 分支；
- 新功能开发完成时，把feature/function_desc 分支代码合并到develop分支（注意：是develop merge feature，方向不能返了），然后进行提测；
- 测试通过后，把feature/function_desc 分支通过MR 合并到master分支，并再master分支标记tag；
- 再次开发新功能时，再重复步骤1即可
bug修复
- 对已经发布的master版本，突然线上发现问题了，需要再master tag1.0的基础上拉取分支 hotfix/bugfix_login , 进行bug修复;
- bug修复完成，分支hotfix/bugfix_login 通过MR合并到master 分支；
循环新功能开发和bug修复两个环节，就构成了我们日常开发基本流程，遵循上述步骤就可以避免因操作不当造成的各种问题，提升开发效率和满足业务需求。
另外，如果想要掌握更全面的git 使用，要掌握git 的其他高级技能 变基 reBase 、stash 这些，可以查看git 教程官网。