文章是正经文章，题目不要在意，哈哈

Git作为当初支流的版本控制工具，然而如何在软件开发过程中进行正当的分支治理是一个见仁见智的问题。

接下来我会比照下现有的几种比拟广泛的分支治理形式和之前在阿里时候应用Aone的区别。

Git Flow

先看一张图片，这张图片来自Vincent在2010年提出的计划，完满的诠释了Git Flow的工作模式。

作为曾经提出了10多年的模式，Git Flow相对来说还算是比较简单的。

稳固的分支就两个：develop和master，这两个分支是不会被删除的，master对应稳固的版本，develop则是用于日常开发的稳固版本。

其余的feature、release、hotfix分支都是用完即删。

feature分支是每个人的开发分支，有新的需要都应该基于develop拉出feature分支进行开发。

release分支则是用于测试和公布的分支。

hotfix用于紧急的bug修复。

开发流程如下：

最开始的时候咱们创立好了master分支，而后基于master分支创立出了develop分支
而后A和B同时基于某个版本的develop分支拉出代码进行开发，分支别离叫做feature-A和feature-B
如果开发过程中须要修复bug上线，那么就从master拉个分支进去，命名为hotfix-xxx进行修复，修复实现之后合并到develop和master，而后hotfix分支删除
而后A代码撸的比拟快，先一步实现了开发，feature-A分支的代码就合并到develop，feature分支被删除，而后咱们基于develop新建一个release-A分支进行测试
测试过程中如果发现问题那么咱们就在release分支修复，把修复的代码合并到develop去
release-A一旦测试实现上线，就把代码合并到master和develop，release分支被删除
这时候B总算把需要开发完了，而后也依照合并到develop，再新建release-B，合并到master和develop的过程来一遍

对于理论利用也比较简单，对于Mac咱们能够间接用最不便的形式进行装置。

首先，装置Git Flow，brew install git-flow-avh，装置好之后执行git flow init就会进行初始化，能够输出你的master和develop分支名字，而后设置其余几个默认分支的前缀。

而后执行git flow feature start irving就能够初始化创立一个feature分支进行开发，默认咱们能够看到是基于develop来创立的。

如果开发实现，咱们执行命令git flow feature finish irving，而后咱们的开发分支就主动合并到了develop，并且开发分支曾经被删除。

接着咱们的分支须要提测和公布，执行命令git flow release start irving，如果修复bug就间接在这下面修复。

测试实现之后，执行命令git flow release finish irving，代码将会被合并到master和develop，而后分支被删除。

原理和实现形式都说了，那么这个模式其实还是一样的问题，就是他比拟适宜固定版本的迭代开发，对于互联网不要脸的每天都要发版，每天10几个需要都要上线来说未免太难了。

develop分支我明天有10个需要，8个要上线，2个不上，代码还有先后顺序依赖之类的，这就没法玩好不好，然而他提供了一个比拟好的标准和思路。

Github Flow

Github Flow能够说非常简单了，它的提出是在2011年，次要就是针对Git Flow。

它就是基于master分支拉一个分支进去开发，而后能够在新的分支中进行开发，实现之后提交pull request，如果承受之后就合并代码部署了。

具体能够看官网介绍。

这个形式简略是简略，然而在很多公司的业务开发过程中个别都有开发、测试、预发、生产几个环境，没有强有力的工具来撑持，我认为很难用这种简略的模式来实现治理。

我感觉这种模式特地适宜小团队，人少，需要少，那就很容易了。

Trunk-Based

这个模型提出的工夫更晚一点，是在2013年Paul Hammant提出的计划。

看图根本就能明确，这不就是SVN的模式嘛，骨干trunk开发，拉出新的分支进行开发部署、修复BUG。

用过的计划

咱们之前用过一个计划，和Git Flow比拟相似，然而不依赖工具的反对，更多的是依附团队自身的约定和标准。

对于开发、测试、预发、生产别离应用分支develop、test、release、master分支，其中master分支作为稳固分支，不能间接提交代码，同时这几个分支是固定惟一的分支。

首先开发阶段，大家都须要基于master创立最新的性能开发分支，命名为feature/xxx。

如果须要公布到开发环境，所有人的代码都须要合并到develop，并且只能用develop分支进行公布开发环境。

如果开发实现，须要提测的分支合并到test分支，那些还在开发阶段的就在develop好了。

测试实现之后须要公布预发(当然叫灰度、uat都行)，就把代码合并到release进行公布。

公布实现之后，代码主动合并到master。

这样做的益处就是首先标准了分支的开发和治理，开发中不会产生太多的纠纷，而且对于同时有多个需要开发并且不同工夫上线都能够做到很好的治理。

毛病就是一个我的项目多个需要开发上线，须要合并屡次代码，从develop、teest到release都要别离合并一次代码并且解决抵触。

总的来说，这只是一个基于团队的标准，对于环境和中间件CI/CD能力没有太多的要求，能够简略的套用在各个公司的场景。

阿里的解决方案

阿里的解决方案基本上能够说是下面几个模式的一个结合体，称作Aone Flow，可能因为工具自身就叫做Aone吧。

分支只有3个，master分支、性能分支feature、公布分支release，其中release分支基本上是不须要开发人员来参加治理的。

首先，分支的创立也都是基于master，如果有需要，首先创立一个feature分支，部署前Aone会主动合并master代码，所以不必操心代码没有合并的问题，如果存在抵触须要手动解决，反之则就主动生成一个新的分支用于部署，这个分支就是release分支。

这个分支能够始终用来公布日常(了解成开发或者测试环境合体)、预发和生产环境。

那如果多个需要同时在开发有抵触不须要合并代码吗？首先，Aone部署能够同时部署多个分支，抉择部署多个性能分支代码会主动合并，如果存在抵触须要手动解决，另外能够独自建设一个环境来部署，互不影响，这个性能真是蛮吊的。

这个规定对于预发和生产环境也是同理。

整个开发过程，咱们不须要管各种分支，只须要一个feature性能分支用于公布各个环境，最终公布实现之后代码主动合并到master主分支（可选项，也能够不合并）。

整个模式看下来就是集成了各个模式的特点，参考了Git Flow的分支的特点，只不过其余的分支不必开发人员关怀，基于骨干master拉出分支开发，主动合并又像是TrunkBased的做法，最终整个流程对于开发人员体验下来又像是更简化版的Github Flow了。

文章参考：
http://www.brofive.org/?p=2165
https://mp.weixin.qq.com/s?__...
https://cloud.tencent.com/dev...