gitflow git flow精简模型

Git版本控制系统因其快速、分布式、轻量级多分支模式的优势，正逐渐取代SVN等集中式版本控制系统。

合理的说，git有相当多的命令，底层的文件模型实际上相当复杂。但是一旦熟练使用，就不用说灵活快速了，往往还有化腐朽为神奇的能力。可以说，如果你熟悉git，那么你就可以轻松地玩；如果你不熟悉它，那么它会和你一起玩。不过话又说回来，很多高级功能在团队协作中经常不用，但是制定了一套简单高效的规范，然后大家就可以遵循这个规范了。

Git自带一套叫做gitflow的多分支工作流机制，可以通过git help workflow在命令行上查看更详细的内容。那么问题来了，什么gitflow？

gitflow是基于Git组织软件开发活动的模型，是基于Git的软件开发的最佳实践。gitflow是一组行为规范和工具，用于在使用Git进行源代码管理时简化一些Git操作。

说白了，其实gitflow已经规定了一些基于git的规范，要求在开发过程中，可以按照其定义的玩法来玩。一般来说，软件开发模型包括通用瀑布模型、迭代开发模型和敏捷开发模型。每个模型都有自己的应用场景。Git Flow重点解决源代码开发过程中各种冲突导致开发活动混乱的问题。所以Git流可以很好的结合现有的各种开发模型使用。

在社区中，有一个成功的，如下图所示。

利用Git创建和管理分支的能力，每个分支被赋予一个特定的含义名称，软件生命周期中的各种活动被合并到不同的分支中。实现了软件开发过程中不同操作的相互隔离。

网上有很多关于这个模式的解释，这里也给出了原作者的解释。有兴趣的可以自己研究。这里就不多解释了，但不可否认，这个想法无疑很好。

离家近一点，其实这个gitflow模型挺复杂的。在实际的开发团队中，完全复制这个机制还是比较少见的，大部分都是以它为指导，在此基础上进行了一些增减。

在上周的小组会议上，大家集中讨论了gitflow的内容。虽然每个人对细节的看法不尽相同，但基本都认为我们应该以此为指导，从最简单的模型入手。

下图是最后讨论的结果。

1.只有三个分支有特殊的含义:主、发布和特性。主分支是主干，也就是说主分支代码是在线运行的代码；发布分支是发布分支，它将承载功能发布、QA回归等流程。特征分支是一个功能分支，承载着特定的功能发展。所有的开发人员都会根据特性分支检查他们自己的个人开发分支。

2.从主服务器签出的分支只能是发布分支和功能分支，并且主服务器上的所有更改都必须来自发布分支。换句话说，除了发布分支之外，所有类型的分支都不允许直接合并到主分支中。这是一个苛刻的要求，否则不能保证主分支的代码质量。言下之意就是主上的代码都来自发布分支，发布分支已经被QA退回，有质量控制。

3.一个人负责检出并合并三个分支:master、release、feature，其他没有操作权限。我们把这个人叫做pudge，意思是屠夫，因为他们都是通过pudge把核心树枝剪下来的。一般pudge也有备份。

4.当一个开发任务来临时，pudge会根据具体的业务从当前的主分支中检出有业务标识的特征分支，比如feature-finds-20161212，分支会带有一个时间戳来表示这个分支大概的生命周期。

5.具体开发人员根据自己的工作和定位，从feature-finds-20161212中检出自己的开发分支，我们称之为RD分支。即图中的RD1、RD2、RD3分支。RD分支机构一般是相互独立的，不需要分支机构名称。因为理论上，除了开发者自己，其他人是不会关注某个具体的RD分支的。当然，多个研发分支可以在同一个功能分支上检出，并且环境相互隔离。

6.经过一段时间的开发，RD分支已经完成了自己的开发任务，开发者应该积极将其RD分支合并到特性分支中。在这个合并过程中，不同的场景可能会有一些额外的操作。例如，如果研发分支分离时间过长，开发人员可以在合并前将功能分支同步到自己的研发分支。开发人员也可以在合并时经历合并请求过程，并将代码审查者指定为其他人或他们自己。理论上，MR在这个环节的合并并没有提出强硬的要求。

7.研发分支合并到特征分支后，测试人员对特征分支进行质量保证。也就是说，测试人员只关注特性分支，其他RD分支不需要关心。

8.如果在功能的质量保证测试中发现问题，通过相关开发进行修复。在自己的研发分支中开发bugfix，然后再次将其合并到功能中。通知测试人员进行回归。

9.如果功能分支测试没有问题，确保可以上线。这时，告诉pudge从master中检出带有日期版本号的发布分支，然后通过mergerrequest将特性分支合并到发布分支中。这一步有两个关键点，一个是pudge从master中检出发布分支，另一个是pudge操作特征分支，通过MR的方式合并到发布分支，另外，当一个发布节点需要同时发布多个特征分支时，我们对多个特征分支重复7、8、9。

10.测试人员在发布分支上执行回归。如果没有问题，就上线发布分支。在线上，pudge将发布分支合并到主分支中。如果发行回归有问题，重复8和9。

11.如果需要紧急处理线上问题或者小问题，比如文案修复。Pudge从master中检出发布分支，并通知相关开发人员评估工作量，是否可以在发布时直接修改，或者是否需要采取更多的分支流程并灵活处理。

主要流程和场景如上所述，要有条理或清晰。在所有的过程中，一个关键的角色就是pudge。基本上这个人负责核心支行的结账、合并、MR操作。对于其他的开发和测试，你只需要关注你需要关心的分支，不需要关注别人。在具体的开发工作中，如果遇到一些不好处理的分支操作，也会由pudge来处理。

微信扫二维码，关注PHP技术！

让知识区无限传播！