开发者学堂课程【ALPD 云架构师系列：云原生 DevOps 36计-阿里云云效出品：常见分支模式优劣对比】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/772/detail/13513
常见分支模式优劣对比
内容介绍：
一、主干开发方式
二、 主干开发并不是银弹
三、 Git-Flow
四、 Github-Flow
五、 Gitlab-Flow
一、主干开发方式
想一想，一个人有冲突吗？有等待吗？一个人在做软件开发的时候，是不会有冲突的，就不需要很多分支，一个分支就够了。如果一个人做开发，不用彼此等待，因为等待的是自己。一个人在做软件开发的时候，其实很简单，做一个分支一条主干道到底想怎么能很快，但是如果人数扩大到10人，100人，效果就很明显了，例如我和张玉之间，两个人协作，其实彼此之间也会有工作的一些隔离，彼此之间可能也会存在着冲突，也会存在着一些等待，但两个人还好，即便有等待，彼此告知一声，马上处理，所以还可以商量一下。在过程当中，发现随着协助的人数越来越多，分析的模式会发生不断的变化，看一下，如果一个人或者一两个人，人很少，常见的一种开发方式叫做 trunk based development，就是主干开发方式。
主干开发方式很简单，是一条主干走到底，开发的过程当中，不会有太多的冲突，是持续的集成到主干上去。在开发过程当中不需要做相应的工作的隔离，所以开发中间其实是所有的开发者在上面频繁的提交，频繁的提成，唯一给出了一个隔离，是release的隔离，就是针对一个代码体现，但是发布的版本不一样，为了把版本之间能够尽可能地隔离开，所以有了一个发布的一个本子。而这里信息同步，是用通过什么样的一个办法呢？是在主干上频繁的持续集成式创新，做到代码的信息同步。所以在 TBD 模式里，是不需要来去做相应的一些分支的一些隔离，信息同步是通过持续频繁的提交来去保持信息。在人数比较少的时候，并且整个公司能力比较强的时候，也是可以用中方，但是随着8个人慢慢的变成了80个人的时候，这时发现开发的人数越来越多，因为参与开发的人数，增加了主干开发的一个冲突几率，所以主干开发它并不是银弹，并不是万能药。
二、 主干开发并不是银弹
主干开发不是银弹
参与开发的人数增加了主干开发的冲突机率
- 参与在主干上的人员越多，代码提交冲突的机率被大。
- 对于一些处在开发过程中的特性，如每次变更提交，并非意味着
完整特性的完成，为了隔离“特性半成品”对主干的影响，一般会采用特性开关(Feature Toggle)）的方式进行隔离。即频繁的代码变更提交，可以先做集成及验证，但是在发布的角度，通过(Feature Toggle)先隐藏相关特性，只有当特性都完成之后，才打开开关，特性完全透出。
- 但是，特性开关的引入也并不是没有成本，因为特性开关是配置
本质上跟我们常常用到的宏定义(#f#else)没啥区别，从本质上，它也是一种代码的分支。特性开关的使用，在一定程度上让你的代码变得更脆弱。
这时主干人越来越多，代码提交充值的几率就越大。而且解决冲突的风险也越来越大，如果十个人的时候，中间可能会产生很多很多的问题。 而且另外一个在主干开发里提到一点，就是要保持信息同步，需要做持续频繁的提交，而且每次提交的力度也很小，就会针对有一些特性，相对只做了半成品，这时要把它提交上去，这时一般会通过特性开关的方式来进行隔离，这是没有完成的一个特性，把开关制成off，这时在做相应的一些提交，但是本身特性开关，其实本质上也是一个分支，同一客观用代码的形式拉了一个分支，但这分支一般是跑不到底，将其打开了才跑到，对本质上其实还是一个分支，而且另外一个特性开关，比如用的特别多，像以前大家比如时间比较久的人，熟悉MFC的时候，知道微软的MFC库有多少宏，这时代码如说特性开关比较多，在一定程度上会把代码变得会很脆弱，维护起来会特别麻烦，这时自然地在想，虽然主干开发时候我很多人在上面，大家冲突几率很大，而且本身特性开发的时候有很多风险，大家彼此之间要去隔离，这时候就引入了另外一种分支方式。
三、Git-Flow
每个人有自己的方式不是很好，看下一种复制模式， git flow这种分支方式，git flow分支方式，就是觉得需要什么分支，就给了什么分支，干什么都有很明确的分支，比如要做基层的，要第二部分支，要做开发的，有必要通知有release分支，每个都是不同的分支，这里，每一个分支的功用都是有确定的，共用的，比如飞车变成是用来做很多个飞船，并行开发的时候，去做相应的一些工作的一个隔离，省得大家彼此之间会有冲突。Release分支是用来做发布的，隔离是发布之间不会有相应的。
在过程当中，发现它很好的做好了隔离，但是在信息同步的过程当中，是基于development频繁的集成来去做信息，并且会在各个分支之间做相应的一些cherry pick replace这种方式来设置相应的一些同步，去同步的时候发现会不会很麻烦，因为分支越来越分支太多，而且一个口从需求到开发到最终发布我要经历好几个分支，分支的流转贸易规则其实是非常麻烦的一个事情。
Git-Flow 也不是“仙丹”
过多的分支，增加了分支管理的复杂度
- 分支特别多，而且每类分支都有特定限定的用法，开发者很难记
住什么分支是干什么的；
- 整个分支模式过于复杂，大大超出大部分团队和项目的需求；
- Feature分支的生命周期过导致的合并冲突。如果一个特性所在
feature分支生命周期过长，它跟develop分支的差异就越大，这样，在该特性集成到develop的过程中，潜在的代码冲突将是集成的噩梦；
- 像develop分支，感觉其实存在的意义不是太大，完全通过
master就可以替代集成的作用，额外为变更提交的集成引入develop:分支，对分支模式来说，变得更加的复杂；同样，如果取消develop分支，hotfix分支存在的意义也就没有必要了，因为这时，hotfix分支与feature分支就没有任何的差别。
尤其是针对 git 不太熟的人来说，发现要去管理要去理解的概念特别多，所以认为git flow 也不简单，过多的分资增加了分支管理的复杂，分支特别多还有分支很复杂，还有另外一个分支虽然有分支，但是分支生命周期特别长，这样合并就会产生一个噩梦，如果拉了六分之五，这是想合并 develop，可能还再过一个月或两个月的时间才能进去，而且另外一个又有 development，有 master，发现其实Develop的分支的意义不是特别大，但是另外一个 feature 品质和 hotfix意义也不是特别大，所以发现 git flow 虽然增加了很多分支，让各种工作尽可能地隔离开，分得非常清，但是信息同步是很麻烦的，而且另外一个就是它本身之间要去管理这些分支，相对难度也特别大了，这时发现需要有通过其他的方式来处理，所以这github，引入了一个分支方式，叫 Github flow，明显比 git flow 简单了很多。
四、Github-Flow
没有 develop，也没有 office，简单就是一个非常称职，当需要开发的时候，拉一个非常本质。然后开发核心 masters 制作发布所以在此过程当中，发现隔离只是在开发过程当中，信息同步是持续的往master来去做集成。
另外一个频繁的从 master 里 pull 代码来去做下来，分享工具来去做同步，这时发布过程当中是基于主干 master。后来去发布，所以没有在发布的过程当中做相应的隔离。
这时又带来一个问题，master 是一个需要做持续集成，是一个集成的地方，也是发布的一个地方，这时一旦集成失败了之后，把所有的工作都阻塞掉了，发也发不了，合也合不进来，这时候发现github flow很简单，可以做的一些隔离，但是本身基础设施或者工程能力比较弱，在这里也会限制整个集成货代发布的一个频率。
五、Gitlab-Flow
这时看到另外一个 gitlab flow和github flow 唯一的区别是在发布过程当中有一个叫做 pre-production 分支。Production 本身它什么呢？
是基于在集成和发布过程当中不同的环境来给了相应的一些分支，其实是完成集成之后，在 master 分支上，这时下一步骤，会先把其拉到prepare预发的分支，commit 的版本已经达到进入一个预发条件了，在完成之后就可以把他再拉到production 功能上，说明已经达到了发布的一个条件。它是一个逐级 promotion 的一个过程，逐步从一个基层的一个环境，摸到一个愈发环境，在屏幕的一个生产环境，简单的过一下我们常见的一些分支方式。
比较一下它们之间的一些优劣，比如 TPD 它分支小，然后实践，做起来非常简单，也不需要太多理解成本，但是，对团队的协作成熟度和纪律都有很高的要求是的，一旦有人不追求，距离一个主干就会成为你的梦魇。
那时就很难去拿去很好的来去做持续的提升，或者发布，没有一个可用的主干，一旦出现问题，Master 是一个工地，一个公共的地方，这时一旦出现问题，所有人都被 blow，这时这些主干方式的一个优缺点看git low that flow与特性之间可以并行开发，规则完善，每个分支的职责特别明确，再大的团队协作，基本上也不会太多的问题，但是分支太多，规则太复杂而且分支生命周期长，合并冲突会比较频繁，尤其像 develop master，是长期存在，但是还要和地方所以看 gitlab flow 也是github flow 可以支持的，但是这里会有一个问题，因为集成只是有一个 must 分支来去做。这里对集成几率有很高的要求，而且集成和发布其实是在一个分支上，这时一旦结成分支中断了所有，不论是集成还是发布都被中断了。
所以到了gitlab flow gitlab flow，是可以支持上面的,因为是非常品质来去做，所以是可以避免开发，但是开发分支还是生命周期长的问题，合并的冲突风险，另外发布分支之间是有耦合的，比如 pro-production 和 production 的分支之间是基于promote 方式来去完成。所以比彼此之间也是一种中断堵塞的这种方式。而且另外一个很多的这种发布分支，因为 pro-production和production 也引入了分支管理， 这种复杂性似的，从这些角度比较，发现没有哪个是绝对好的，或者哪个是绝对差。
其实分析的角度来说，有一个简单的一个原则，就是要去控制分支的数目，然后小批量频繁的集成控制分支的数目，可以去做到工作隔离，但是又不会增加太多的管理成本，是小批量频繁的提成，可以加速信息的同步。这里的分支数目其实并不是可以只能有一个非常城市或者别的分支类型的一个数目。给到了一个一个简单的要从最大化生产力和最小化风险的角度来去思考。就是尽可能的控制分支的数目，和小批量频繁一个集成。
控制分支数目，小批量频繁集成
- 最大化生产力（Maximum Productivity):所有人工作在共同区
域内。除了一条长期，不被中断的开发主干外，没有任何分支。也并无其他需要制定的规则，代码的提交过程相当简单。但是，每一次的代码提交，都有可能被破坏整个项目的集成，进而导致项目进度的中断。
- 最小化风险（Minimum Risk):所有人都工作自己的分支上。每个
人的工作是相互独立的，没人可以打断其他人的工作，这样，减少了开发被打断的风险。但是，这种做法增加了额外的流程负担，同时，协作变得非常困难，所有人都不得不谨小慎微地合并自己的代码，即便是整个系统中非常小的一部分也是如此。
