Git 的一大特点就是可以创建很多分支并行开发。正因为它的灵活性，团队中如果没有一个成熟的分支模型的话，那将会是一团糟。
分支模型
有个比较成熟的分支模型git flow。需要注意的是，它只是一个模型，而不是一个工具；你可以用工具去应用这个模型，也可以用最朴实的命令行。所以，重要的是理解概念，不要执着于实行的手段。
简单理解几个概念：
- master-最为稳定功能最为完整的随时可发布的代码;
- hotfix——修复线上代码的 bug；
- develop——永远是功能最新最全的分支；
- feature——某个功能点正在开发阶段；
- release——发布定期要上线的功能。
「master」和「develop」是主要分支，其他分支是派生而来的。各类型分支之间的关系用一张图来体现
开发流程
1.开发接收需求，切换到develop分支，pull develop分支最新代码，拉取特性分支feature；
2.每一个新功能的开发都应该各自使用独立的feature分支。为了备份或便于团队之间的合作，这种分支也可以被推送到中央仓库，B和A可以同时在一个特性分支上协作。
3.功能开发完毕并且自测后，先切换到 develop分支，pull最新代码，切回功能所在的feature，把develop分支的代码合并进来，有冲突和配合的人一起解决。
4.到 GitLab 上的项目首页创建feature合并到develop的合并请求（merge request），比对和上个版本的代码变化，指定有合并的和参与代码审核的同事。（代码审核）
5.项目负责人在收到合并请求时，应该先做下代码审核看看有没有明显的严重的错误；有问题就找负责开发的人去修改，没有就接受请求并删除对应的 feature 分支。
有问题的代码开发者自己修改后在push到仓库，代码审核页面会同步最新修改。
6.负责测试的人从develop创建一个 release 分支部署到测试环境进行测试，若发现了 bug，相应的开发人员就在 release 分支上或者基于 release 分支创建一个分支进行修复。
7.当确保某次发布的功能可以发布时，负责发布的人将 release 分支合并进 master 和 develop 并打上 tag，然后打包发布到线上环境。
流程图如下：
实际开发中会有几个问题：
1.同时维护master和develop两个分支很耗时，每次release分支发完版都要同步回master&develop；
2.功能并行开发时，无法及时同步上线和测试节点；
某个业务方的测试现在需要测试，但是不再这个版本，就无法操作。因为release分支是从develop上拉取的，同一个节点不能合并不再本期发版计划的代码step[5]
测试环境也只能同时发布一个分支step[6]
3.审核代码后再次修改审核。step[6]&step[4]
推荐方案
我们简单的维护两个主要分支，不再维护release分支。
master -- 功能最稳定，线上正在运行，可随时发版，受保护的分支。
develop(test) -- 是功能最新最全的分支，也是部署在测试环境的分支，在我们这也可以部署在debug环境。
优化后的开发流程：
1.开发者pull master最新代码，拉取feature分支 统一命名风格：feature_seckillCoupon_denghuanqing_20181223
2.在feature分支上完成开发自测后，切换到test分支，pull最新代码，把feature分支合并到test分支，可能会出现冲突，和协作同事商量解决。
注意，非简单的解决featue a 和test分支冲突，需要商量是feature a还是feature b需要调整代码，假若feature a需要调整代码，feature a调整代码，合并到test分支。feature b 重新操作合并到test分支。
3.通知测试在测试分支测试，这个阶段不用关心发版进程，除非业务互相依赖。bug也在feature分支修改，修复完成后合并流程参考step2;
4.测试完全通过后，开发切换到master分支，pull最新代码，切换回feature分支，把master分支合并到feature分支（保证即将发布的代码没冲突），在gitlab提交合并请求，写上功能需求点，脚本等，指定项目管理员审核并且合并代码。
5.管理员审核代码，处理（本次版本内）合并请求，打tag，发版，走线上验证流程。
6.完成功能开发。feature可以保留几周后统一清理，我时常会在功能分支上找一些写过的代码。
7.备注:修改线上的bug重新从master拉去分支或者使用未被污染的feature分支都ok。
gitlab操作演示
1.保护分支
2.提交合并请求
项目首页点击下拉框
3.选择要把那个分支合并到master
4.填写本次发版相关描述，比对代码差异。确认提交后通知相关权限用户。（gitlab同时提供邮件通知）
