痛！痛！痛！咱们的好兄弟Git，一路走好！
文章是正经文章，标题不要在乎，哈哈
Git做为如今主流的版本控制工具，可是如何在软件开发过程当中进行合理的分支管理是一个见仁见智的问题。git
接下来我会对比下现有的几种比较广泛的分支管理方式和以前在阿里时候使用Aone的区别。github
Git Flow
先看一张图片，这张图片来自Vincent在2010年提出的方案，完美的诠释了Git Flow的工做模式。ide
做为已经提出了10多年的模式，Git Flow相对来讲还算是比较简单的。工具
稳定的分支就两个：develop和master，这两个分支是不会被删除的，master对应稳定的版本，develop则是用于平常开发的稳定版本。post
其余的feature、release、hotfix分支都是用完即删。测试
feature分支是每一个人的开发分支，有新的需求都应该基于develop拉出feature分支进行开发。ui
release分支则是用于测试和发布的分支。阿里云
hotfix用于紧急的bug修复。spa
开发流程以下：版本控制
- 最开始的时候咱们建立好了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