感谢WHS，关注了另外一个Git风格的分支管理模型，GitLab Flow是2014年由GitLab正式发布的。看了一下GitLab的成员，遍布整个世界，开始还以为GitFlow是其中某个哥们总结写下的，后来仔细一看，是他们的CEO Sid Sijbrandij写下来的！！按照Sid的说法。GitLab Flow最大的特点是将FDD、Feature分支与Issue Tracking 结合在一起了。让我们看看到底是什么样的。

本系列一共3篇文章：

（1）GitFlow、GitHubFlow 和 TBD

（2）GitLab Flow

（3）Atlassian Simple Git Flow & Google Upstrea

一、关于分支模型

Sid认为Gitflow过于复杂，而且由于将Master分支用于交付，导致很多默认在master分支集成的工具难以使用。而GitHub Flow又显得过于简单。上述两者均有一定的适用场景，而Sid认为GitLab Flow是面向CD的场景，因此各种设计要面向CD的需求，包括如下：

1、尽可能延后Release分支（准备交付）的创建，以便集成更多的Fix和Feature

2、考虑到Master是工具链阶段性交付的，这个节奏和版本交付节奏肯定有差异，需要考虑隔离Master和Production

3、如果涉及到较多的现场环境测试，还可以建立另外一个Pre-Production分支

4、master –>pre-production –> production是正常的bugfix提交次序，即便是对于紧急patch，也要尽可能遵循上游优先更新的策略

仔细看这个图，是不是非常类似GitFlow的develop、Release和master分支。从含义上看，他们的作用非常类似，但是名字不同。GitLab Flow的命名规则更接近传统的开发者习惯。

二、Merge/Pull Request

CVS、SVN用户表示非常羡慕能有一些管理性工具，GitLab用Merge Request代替Pull Request还是有些道理的。In GitLab it is common to protect the long-lived branches (e.g. the master branch) so that normal developers can’t modify these protected branches. So if you want to merge it into a protected branch you assign it to someone with maintainer authorizations

三、Issue Tracking和GitLab Flow

In GitLab each change to the codebase starts with an issue in the issue tracking system. If there is no issue yet it should be created first provided there is significant work involved (more than 1 hour). For many organizations this will be natural since the issue will have to be estimated for the sprint. Issue titles should describe the desired state of the system, e.g. “As an administrator I want to remove users without receiving an error” instead of “Admin can’t remove users.”.

When you are done or want to discuss the code you open a merge request. This is an online place to discuss the change and review the code. Opening a merge request is a manual action since you do not always want to merge a new branch you push, it could be a long-running environment or release branch. If you open the merge request but do not assign it to anyone it is a ‘Work In Progress’ merge request. These are used to discuss the proposed implementation but are not ready for inclusion in the master branch yet. Pro tip: Start the title of the merge request with [WIP] or WIP: to prevent it from being merged before it’s ready.

小结：看过以后可以明白为什么Sid说GitLab Flow最大的特点是Issue tracking和开发集成了。因为GitLab Flow的分支和GitHub Flow颇有些相似，复杂的GitLab Flow和GitFLow也有些形似。最大的差异当然就是他们自己开发的管理工具了。

毕竟，无论GitLab还是GitHub都是在Git外面包装了一套管理工具，并没有谁比谁更高明的说法。而具体的分支策略，一定要和公司的开发文化结合在一起。附上Forrester Wave最新的CI象限图，GitLab是第一名

相关信息：

Introduction to GitLab Flow