学习阿里的分支管理模式

对于公司的分支管理，只是觉得很乱，但怎么改善也没啥好想法。 今天看到了阿里的林帆同学的博客，总结的挺好的。摘抄一下。 文中所有图片，都是来自林帆同学的博客，因为微信不让引用图片，所以拷贝过来的，请见谅。

原文地址： https://mp.weixin.qq.com/s?__biz=MzAxNDU0MTE0OA==&mid=2661008528&idx=1&sn=748c3b5bdaa28c3c7b3c06614fd69d47&chksm=80feaca3b78925b5a1b9d3f075e398c567d593ebf091d9d581d8492977b347d2a7ff1e67c153&scene=21#wechat_redirect

 

每个公司都希望有一套好的分支管理模式，但是又没有一套模式能够满足所有公司的需要。 我们常常听说的模式有 TrunkBased和GitFlow（我真的仅仅是听说过哈）

 

大概记录下这2中模式的特点吧：

TrunkBased：体现的是持续集成的思想，由单个主干分支和许多发布分支构成。每个发布分支是在特定版本的提交点上从主干创建出来的。发布分支用于线上部署或者hotfix。 缺点是，太多的人同时工作在主干上，到发布的时候可能发生灾难。

 

GitFlow：由一个主干分支，一个开发分支、许多特性分支和许多发布分支，以及hotfix分支构成，以及许多繁琐的合并规则构成。 （太繁琐了，不想继续看下去了）

 

还是说说今天的主角吧

AoneFlow：阿里内部用的分支管理模式。这个模式在阿里表现好，有上下游工具平台提供支持的原因。但对我来说不是问题，我就是单纯想找一种思路清晰，可操作性强的分支管理模式。

 

AoneFlow使用了3中分支类型： 主干分支，特性分支，和发布分支，以及三条基本规则

规则一： 开始工作前，从主干创建特性分支

无论是要开发新功能，还行修改bug，都要从代表最新已发布版本的主干上创建一个特性分支。 也就是说一项工作就对应一个特性分支，这些分支不允许直接提交到主干。

规则二：通过合并特性分支，形成发布分支

这个是这个模式的精髓所在了。  创建发布分支的过程是，从主干上拉出一个新的分支，将所有本次要集成或发布的特性分支一次合并进去，从而得到发布分支。 这个地方灵活性非常大，可以随时调整发布版本所包含的特性，很容易调整，也可以为不同环境提供包括不同功能的版本等。

这里有个麻烦，某个版本，合并哪些特性分支，最好能有工具进行辅助。另外，如果特性分支能够与需求一一对应就更好了。

 

规则三：发布到线上后，合并相应的发布分支到主分支，在主干添加标签，同时删除该发布分支所关联的特性分支。

始终保持，主干分支与线上版本一致。