一、目的
为了减少在团队协作开发时因分支管理不当而出现的代码丢失、错乱情况，需要一套标准规范来约定分支的相关操作；主要针对分支命名规范、分支操作流程进行说明
二、分支命名约定
-
master分支：公共分支，可以随时编译对外发布的稳定版本，不允许直接push 代码，只接受feature/hotfix分支通过MR 操作合并代码；当一个版本的所有功能再develop 测试通过后，在本地pull 拉取最新master 代码，切换到开发feature分支，把master 分支merge 到 feature 分支（这一步一定要做，保证远程MR一定会成功），把冲突在本地解决，之后把该分支push 到远程，在远程 通过MR 合并远程master 分支，然后再更新本地master分支，并再本地打版本tag，再推送tag到远程；
-
develop 分支：公共分支，该分支主要用于合并代码并打包测试，而非功能开发，但不能合并到master； 禁止在该分支开发commit 代码，只能通过feature分支在本地 merge 合并代码，把冲突在本地解决，然后push到远程；把feature分支合并develop 分支时，要先从服务端pull 一遍拉取最新代码（有可能别人push了新的代码），然后再进行本地merge 操作；
-
feature分支：独立分支（命名以feature/function_desc），feature 分支主要用来开发功能，而非打包测试。开发完成之后，切到develop分支之后，按照develop 中的描述进行分支合并打包；Feature分支开发完成可以选择删除或者保留，feature分支的创建最好以功能特征来命名，每一个功能对应一个feature分支，这样做的好处就是代码提交日志清晰集中、功能并行开发切换自由；
-
hotfix分支: 独立分支(命名以hotfix/开始)，一般用于修复已发布版本的bug，直接从master上拉取。bug修复完成后，然后以feature 分支合并到master为样本，再操作一次 hotfix 分支即可。
总结：1. merge 操作之前，一定要pull 拉取当前分支的最新代码；2. 解决代码合并的冲突，一定是在本地进行的；3. 公共分支 不能进行commit操作，只能本地merge 或者远程 merger （MR）来合并代码 4. 每个分支都有一个 Life cycle ，下面我来一一解释一下
三、流程图
这里为了简单起见，没有创建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 教程官网。
