文章是正经文章，标题不要在意，哈哈
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 FlowGithub Flow可以说非常简单了，它的提出是在2011年，主要就是针对Git Flow。
它就是基于master分支拉一个分支出来开发，然后可以在新的分支中进行开发，完成之后提交pull request，如果接受之后就合并代码部署了。
具体可以看官方介绍。
这个方式简单是简单，但是在很多公司的业务开发过程中一般都有开发、测试、预发、生产几个环境，没有强有力的工具来支撑，我认为很难用这种简单的模式来实现管理。
我觉得这种模式特别适合小团队，人少，需求少，那就很容易了。
Trunk-Based这个模型提出的时间更晚一点，是在2013年Paul Hammant提出的方案。
看图基本就能明白，这不就是SVN的模式嘛，主干trunk开发，拉出新的分支进行开发部署、修复BUG。