什么是Git-Flow
在使用Git的过程中如果没有清晰流程和规划，否则,每个人都提交一堆杂乱无章的commit,项目很快就会变得难以协调和维护。
Git版本管理同样需要一个清晰的流程和规范。 Vincent Driessen 为了解决这个问题提出了 A Successful Git Branching Model 以下是基于Vincent Driessen提出的Git Flow 流程图
-
Production 分支
也就是我们经常使用的Master分支，这个分支最近发布到生产环境的代码，最近发布的Release， 这个分支只能从其他分支合并，不能在这个分支直接修改
-
Develop 分支
这个分支是我们是我们的主开发分支，包含所有要发布到下一个Release的代码，这个主要合并与其他分支，比如Feature分支
-
Feature 分支
这个分支主要是用来开发一个新的功能，一旦开发完成，我们合并回Develop分支进入下一个Release
-
Release分支
当你需要一个发布一个新Release的时候，我们基于Develop分支创建一个Release分支，完成Release后，我们合并到Master和Develop分支
-
Hotfix分支
当我们在Production发现新的Bug时候，我们需要创建一个Hotfix, 完成Hotfix后，我们合并回Master和Develop分支，所以Hotfix的改动会进入下一个Release
Git设置
- Git-Flow 要求 Git merge 不使用 fast-forward 这样能让Git各个分支的流向更加清晰
$ git config --global merge.ff false # 全局设置Git merge 取消 fastforward
$ git config --global merge.ff false # 个别仓库设置为 merge 取消 fastforward</pre>
-
权限设置
设置分支merge的权限，只有享有merge权限的责任人才能submit merge请求，没有merge权限的只能提交merge请求。将master，develop，release三个分支设置成只允许maintainers merge，不允许任何人push，杜绝从本地merge，push到远端的情况。
具体设置位置：
项目首页→Settings->Repository→Protected Branches
Git Flow 如何使用
-
Master/Devlop 分支
所有在Master分支上的Commit应该打上Tag，一般情况下Master不存在Commit，Devlop分支基于Master分支创建
-
Feature 分支
Feature分支做完后，必须合并回Develop分支, 合并完分支后一般会删点这个Feature分支，毕竟保留下来意义也不大。
-
Release 分支
Release分支基于Develop分支创建，打完Release分支之后，我们可以在这个Release分支上测试，修改Bug等。同时，其它开发人员可以基于Develop分支新建Feature (记住：一旦打了Release分支之后不要从Develop分支上合并新的改动到Release分支)发布Release分支时，合并Release到Master和Develop， 同时在Master分支上打个Tag记住Release版本号，然后可以删除Release分支了。
-
Hotfix 分支
hotfix分支基于Master分支创建，开发完后需要合并回Master和Develop分支，同时在Master上打一个tag。
Git-flow 命令请参考 ：Git Flow 的正确使用姿势 中命令行篇章
Merge Request
GitLab中的Merge Request指的是把代码从一个分支合并到另一个分支上做的操作。
Merge Request 可以进行代码审查以及我们遵循的现有代码审查最佳实践来改进工作流程。
简单来说就是将完成的新功能分支，请求主程序员进行合并，在此过程中code review，解决冲突等
具体 Merge Request 细节请参考： 保姆级教程 |Merge Request 分支合并请求 - SegmentFault 思否
Merge Request主要用于代码的合并与审核，团队成员在完成新功能开发后，在本地测试没问题后需要提交合并请求（简称MR），主程序员收到MR请求，需要在请求中进行代码的合并和审查，通过后可以进行合并。
步骤：
编写代码并将其推送到单独的分支。
为主要开发分支创建合并请求。 Assignee以及说明字段和评论中被提到的那些人将通过电子邮件通知合并请求。如果需要某一位开发人员关注，你可以在描述字段中@该名开发人员。
等到MR被接受或拒绝，并提供有关必要修复的评论。
参与有关修复的讨论。 （GitLab允许回复评论）
修复。
将更改推送到你的分支。
打开一个新合并如果最后一个MR被关闭（如果合并请求未关闭，它将自动更新，直到最后一次提交为止）。
通过注释合并请求或以其他方式报告已实施的修复。
对Merge Request不了解的同学请务必参考 保姆级教程 |Merge Request 分支合并请求 - SegmentFault 思否，因为这关系到代码的合并与功能的考核。
团队具体实施
首先需要在每个项目中确定主开发程序员，负责管理主要分支（develop、master）的合并与线上版本的管理
主程序员新建Git仓库，新建master分支与dev分支，并以这两个分支为主线进行Git-Flow管理
主开发程序员在团队开发时，负责分发任务，与成员协商新建feature分支进行新功能开发
成员feature分支开发完成，需要在gitlab提交上请求合并（Merge Request）
如果成员提交时dev已经推进数个新功能，建议成员在MR前先在本地feature分支手动合并dev分支，这样可以有效减少冲突，提高效率（重要！）
git pull # 保持dev最新 git checkout feature-many-commits git merge dev # 如果在这一步发生冲突，那么手动解决冲突即可 git push
主程序员查看Merge Request并进行分支合并（可能会遇到冲突，要协商解决）和代码审查
新功能完成开发后，主程序员新建release分支用于测试环境测试，测试环境有bug修复完后合并回dev分支并以此循环
版本测试完成后，发布线上版本到master分支，并且打上tag
如果线上版本出现问题，则新建hotfix分支进行紧急修复（参考Git-Flow规范）
