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

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

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

Git Flow

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

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

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

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

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

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

hotfix 用于紧急的 bug 修复。

开发流程如下：

1. 最开始的时候咱们创立好了 master 分支，而后基于 master 分支创立出了 develop 分支
2. 而后 A 和 B 同时基于某个版本的 develop 分支拉出代码进行开发，分支别离叫做 feature- A 和 feature-B
3. 如果开发过程中须要修复 bug 上线，那么就从 master 拉个分支进去，命名为 hotfix-xxx 进行修复，修复实现之后合并到 develop 和 master，而后 hotfix 分支删除
4. 而后 A 代码撸的比拟快，先一步实现了开发，feature- A 分支的代码就合并到 develop，feature 分支被删除，而后咱们基于 develop 新建一个 release- A 分支进行测试
5. 测试过程中如果发现问题那么咱们就在 release 分支修复，把修复的代码合并到 develop 去
6. release- A 一旦测试实现上线，就把代码合并到 master 和 develop，release 分支被删除
7. 这时候 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…