转载

git flow精简模型

Git版本控制系统因为其快速、分布式、轻量的多分支模型等优点，现在正在逐步取代SVN等集中式版本控制系统。

讲道理的话，git的命令其实挺多的，而且底层的文件模型其实挺复杂的，但是一旦熟练使用的话，灵活、快速这些特点就不必说了，很多时候更有化腐朽为神奇的能力。可以这么说，如果你熟悉git的话，那么你玩起来得心应手，如果你不熟悉的话，那么就是它玩你了。不过话说回来，团队协作中，往往不会用到很多高级的特性（比如cherry-pick、rebase、压缩历史、拆分提交等等），而是制定一套简单高效的规范，然后大家都去follow这个规范即可。

git自带一套多分支工作流机制，名为gitflow，在命令行中可以 git help workflow 查看更加详细的机制。那么问题来了，什么gitflow？

gitflow是构建在Git之上的一个组织软件开发活动的模型，是在Git之上构建的一项软件开发最佳实践。gitflow是一套使用Git进行源代码管理时的一套行为规范和简化部分Git操作的工具。

说的直白点，其实gitflow就是基于git规定了一些规范，要求在开发过程中，按照它定义的玩法来玩即可。一般而言，软件开发模型有常见的瀑布模型、迭代开发模型、以及敏捷开发模型等不同的模型。每种模型有各自应用场景。Git Flow重点解决的是由于源代码在开发过程中的各种冲突导致开发活动混乱的问题。因此，Git flow可以很好的于各种现有开发模型相结合使用。

社区中，有一个比较成功的 gitflow模型，如下图所示，

git flow精简模型

利用Git创建和管理分支的能力，为每个分支设定具有特定的含义名称，并将软件生命周期中的各类活动归并到不同的分支上。实现了软件开发过程不同操作的相互隔离。

关于这个模型网上有很多的解释，这里也给出了原作者的文章链接，有兴趣的可以自己去研读一下。我这里就不做过多解释了，但是不可否认这个思路无疑是非常棒的。

言归正传，其实这个gitflow模型还是挺复杂的，在实际中的开发团队中，完全照搬这套机制的还是比较少的，大部分都是以之为指导，在其基础之上做了一些增减。

组里面在上周的周会中，大家集中头脑风暴了gitflow这块的内容。大家虽然在细节上的观点不一致，但是基本上都认为应该以其为指导，从最精简的模型上手。

下面是这张图是最终的讨论后的结果，

git flow精简模型

1，有特殊含义的分支只有三种：master、release、feature。master分支为主干，其含义是master分支代码就是线上跑的代码；release分支为发布分支，它会承载功能发布、QA回归等流程；feature分支为功能分支，它承载了具体的功能开发，所有的开发者都将基于feature分支签出自己的个人开发分支。

2，从master签出的分支只能是release和feature分支，master上的改动必然都是来自release分支。换句话说，除了release分支，其他的所有类型的分支都不允许直接合并到master分支。这一点是强硬要求，否则无法保证master分支的代码质量。言下之意，master上的代码都是来自release分支，而release分支都是经过QA回归过，有质量把关的。

3，master、release、feature这三个分支的签出与合并都由一个人来操作，其他人没有操作权限。我们把这个人称之为pudge，屠夫的意思，因为都是通过pudge切割出来一个个核心分支。一般pudge还有一个backup。

4，当有开发任务过来时，pudge按照具体的业务从当前的master分支签出带有业务标识的feature分支，比如 feature-finds-20161212 ，同时分支会带有时间戳来表达此分支大致的生命周期。

5，具体的开发人员按照自己的工种和定位，从 feature-finds-20161212 上签出自己的开发分支，我们称之为RD分支。即图中的RD1，RD2，RD3分支。RD分支一般而已都是相互独立的，分支名不作要求。因为除了开发者自己，其他人理论上是不会关注某一个具体的RD分支的。当然，同一个feature分支上可以签出多个RD分支，环境相互隔离。

6，经过一段时间的开发后，RD分支完成自己的开发任务了，开发者要主动将自己的RD分支合并至feature分支。这个合并过程中，在不同的场景下，可能会有一些额外的操作。比如RD分支游离的时间过长，开发者可以先同步feature分支到自己的RD分支，然后再合并。开发者也可以在合并的时候走Merge Request流程，将Code Reviewer指定为他人或自己。理论上MR在此环节的合并不作强硬要求。

7，RD分支合并进feature分支之后，通过测试人员针对feature分支进行QA。也就说，测试人员只关注feature分支，其他的RD分支不需要care。

8，若测试在feature上QA时发现有问题，通过相关的开发去修复。开发在自己的RD分支进行bugfix，完毕后再次合并到feature。通知测试人员进行回归。

9，若feature分支的测试无问题，确定可以上线。此时通知pudge从master签出带有日期版本号的release分支，然后通过Merge Request将feature分支合并进release分支。这一步有两个关键点，一个是由pudge从master签出release分支，另一个是由pudge来操作feature分支通过MR的方式合并进release分支。此外，当某一个release节点需要同时发布多个feature分支，那我们就针对多个feature分支重复7，8，9。

10，测试人员在release分支上进行回归。若无问题，即对release分支走上线流程（注意：这里是对release而不是master）。上线完毕，由pudge将release分支合并进master。若release的回归出现问题，则重复8，9。

11，若需要紧急处理线上问题或者一些小问题，比如文案修复之类的。由pudge从master签出release分支，通知相关开发人员评估工作量，能否直接在release上修改，还是需要走更多的分支流程，灵活处理。

主要的流程和场景如上所述，应该条理还是比较清晰的。所有的流程中，有一个关键角色，就是pudge。基本上核心分支的签出、合并、MR操作都是由这个人来完成。其他的开发和测试，只需要关注自己需要关心的分支即可，其他的不用关注。在具体的开发工作中，若遇到一些不太好处理的分支操作，也都交由pudge来处理。

原文 http://blog.gejiawen.com/2016/12/12/git-flow-compact-model/

正文到此结束