Git-flow分支管理与Aone-flow分支管理对比

gitflow_2">git-flow分支管理：

master: 主分支，主要用来版本发布。
hotfix：线上 bug 紧急修复用到的临时分支。这个分支用来修复主线master的BUG
release（预发布分支）：release 分支可以认为是 master 分支的未测试版。比如说某一期的功能全部开发完成，那么就将 develop 分支合并到 release 分支，测试没有问题并且到了发布日期就合并到 master 分支，进行发布。
develop（相当于release的预分支）：日常开发分支，该分支正常保存了开发的最新代码。
feature：具体的功能开发分支，只与 develop 分支交互。

个人总结

优点：
经过多次实践，并行特性开发良好。
适合大型项目开发，对小中型项目而言，过于繁杂，降低敏捷性。
公司协同性比较高的话适合使用，或者公司有专门的git管理部门统一管理分支。
缺点：
从项目开始到上线过程中需要开的新分支过多不易维护，而且多分支容易出错。
对于测试来说增加工作量，develop一套分支代码会同时承载两个环境，一个dev环境供开发使用，一个test环境供测试使用。所以测试过程先是开发人员在feature分支自测，然后是测试人员在dev环境测试，之后是在release环境还要测试，最后才能合到master上线。当hotfix分支合并入到release分支的时候,release分支必须得再次验证，纵使release上的功能全都验证通过。（繁琐的自测和测试人员的重复测试流程，测试人员比较少或者有其他项目需要测试）拖长项目的迭代周期。
对于项目经理而言，管理这些分支需要消耗比较多的精力，需要根据不同情况选择性的去拉取或者删除不同的分支，不仅在feature分支合并代码到dev时候，如果有并行诉求需及时判断并行中哪条是需要延时合入的，这在敏捷开发或者快速迭代过程中会有工作负担。而且在release分支上上行合并和下行合并时也会有问题，这里开发人员可以在release上进行修改代码。针对线上bug根据紧急程度由经理决定决定是否使用hotfix分支。
分支越多，生命周期越短，这种出错的概率就越大。merge代码总是痛苦和易错的。在软件开发的世界里，如果一件事很痛苦，那就频繁地去做它。feature branch这个实践本身阻碍了频繁的merge: 因为不同feature branch只能从master或develop分支pull代码，而在较长周期的开发完成后才被merge回master。也就是说相对不同的feature branch，develop上的代码永远是过时的。如果feature开发的平均时间是一个月，feature A所基于的代码可能在一个月前已经被feature B所修改掉了，这一个月来一直是基于错误的代码进行开发，而直到feature branch B被merge回develop才能获得反馈，到最后merge的成本是非常高的。
git-flow大量的合并冲突和对集成测试不友好。

Aone-flow分支管理：

它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。
AoneFlow 只使用三种分支类型：master分支、feature分支、release分支，以及三条基本规则
规则一（开始工作前，从主干创建特性分支）
AoneFlow 的特性分支基本借鉴 GitFlow，没有什么特别之处。每当开始一件新的工作项（比如新的功能或是待解决的问题）的时候，从代表最新已发布版本的主干上创建一个通常以feature/前缀命名的特性分支，然后在这个分支上提交代码修改。也就是说，每个工作项（可以是一个人完成，或是多个人协作完成）对应一个特性分支，所有的修改都不允许直接提交到主干
规则二（通过合并特性分支，形成发布分支）
AoneFlow 的发布分支设计十分巧妙，可谓整个体系的精髓。GitFlow 先将已经完成的特性分支合并回公共主线（即开发分支），然后从公共主线拉出发布分支。TrunkBased 同样是等所有需要的特性都在主干分支上开发完成，然后从主干分支的特定位置拉出发布分支。而 AoneFlow 的思路是，从主干上拉出一条新分支，将所有本次要集成或发布的特性分支依次合并过去，从而得到发布分支。发布分支通常以release/前缀命名。
规则三，发布到线上正式环境后，合并相应的发布分支到主干，在主干添加标签，同时删除该发布分支关联的特性分支。
当一条发布分支上的流水线完成了一次线上正式环境的部署，就意味着相应的功能真正的发布了，此时应该将这条发布分支合并到主干。为了避免在代码仓库里堆积大量历史上的特性分支，还应该清理掉已经上线部分特性分支。与 GitFlow 相似，主干分支上的最新版本始终与线上版本一致，如果要回溯历史版本，只需在主干分支上找到相应的版本标签即可。
除了基本规则，还有一些实际操作中不成文的技巧。比如上线后的 Hotfix，正常的处理方法应该是，创建一条新的发布分支，对应线上环境（相当于 Hotfix 分支），同时为这个分支创建临时流水线，以保障必要的发布前检查和冒烟测试能够自动执行。但其实还有一种简便方法是，将线上正式环境对应的发布分支上关联的特性分支全部清退掉，在这个发布分支上直接进行修改，改完利用现成的流水线自动发布。如果非得修一个历史版本的 Bug 怎么办呢？那就老老实实的在主干分支找到版本标签位置，然后从那个位置创建 Hotfix 分支吧，不过由于阿里的产品大多是线上 SaaS 业务，这样的场景并不多见。
正是这些简单的规则，组成了 AoneFlow 独树一帜的核心套路。

个人总结：

规则易懂，三条规则。
它基本上兼顾了 TrunkBased 的“易于持续集成”和 GitFlow 的“易于管理需求”特点，同时规避掉 GitFlow 的那些繁文缛节。
AoneFlow 只使用三种分支类型：master分支、feature分支、release分支，以及三条基本规则。
一个主干分支+N个特性分支+N个发布分支
相对git-flow而言的优势：
AoneFlow 的发布分支是相对固定的，因此相比 GitFlow 更易于进行持续集成。
经过阿里团队长期实践，稳定性很高。项目管理相比却更加容易和高效，去除一些繁琐步骤。
每次有新需求时，从当前主干分支拉取一个特性分支。多个特性分支可同步开发，到发布时间节点时，根据不同的环境合并不同的分支。
对于维护不同环境和不同版本的情况下非常适用，不会产生多余的分支，主干分支与线上环境保持一致。
使用Aone-flow最好有良好的代码规范和配套的工具，比如：用于线上发布的代码，不可以使用包含“SNAPSHOT 版本”（即未正式发布版本）的依赖包，从而确保每次构建出的产物都是一致的等等细节需要关注。工具考虑的话可以了解一下阿里的云效。
总体而言，Aone-flow相对于不同项目的管理而言，相比git-flow我觉得更加高效。分支方面可由相应组长或者项目经理进行管理，工作量也不算大。