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了。
文章参考：
