这次学委讲讲开源项目的分支管理，帮助读者了解开源项目是怎么管理代码的。
多数开源项目都是main（以前是master/trunk）分支管理代码的。
开发版本或者中间修订版本走feature 分支发布，然后再定期合并到master 分支。
分支管理是什么
分支管理，简单理解，就是多条生产线管理，比如一款手机的多个版本的生产。
比如某个手机的三条生产线：
现售的Mate30手机，在装订生产。
同时还有Mate20旧版本还有部分销售订单还在继续装订。
新版本Mate40还在研发
这样就好理解，我们的项目代码就是制作手机的输入，通过管理多个分支，让不同产品线团队做到最大程度的独立开发，发布不同款式产品。
下面介绍一下著名开源项目和我们做开源项目应该怎么进行分支管理的
第一种 基于主干分支管理（Trunk Based）比如LINUX内核
我们打开Linux内核的主线repo，看到如下的分支，只有master主干分支。
非常简单，也比较典型的主干为中心的分支管理。
因为linux内核主线只有一个，新的特性代码会被不断提交到主线，新内核也没有必要支持向后移植。
如果需要得用指定的tag来检出特定版本分支，进行修订发行。
就像下图一样，以trunk分支为中心，每一个弯都是一个PR（Pull Request），合并到trunk分支。
学委补充一下PR，PR代表每次有效开发工作的提交与合并。
主干分支管理的好坏：
好处：简化管理，所有特性只要审核通过马上合并到主干分支。这样随时可以发布，也避免了出现大规模集成的风险。
缺点：一个个单一的提交造成问题不大，不过当出现颠覆式的提交或者多个提交，这些提交造成的问题会一直影响主干分支，也影响到每次发布，直到问题解决。
小伙伴可能有疑问了，那么稳定发行版本，如何进行打补丁（比如遇到bug或者安全漏洞需要提交修改）
稳定版本仓库：
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/linux还有一个独立的stable 仓库，它基于主线分支的一次镜像（或者定期同步，主要是发行大版本的时候）。
确定了发行的主版本后，做一个分支发布为stable仓库，后续比较急的补丁都打在stable分支上，然后再回顾这些提交，发布到内核仓库的主干分支。
第二种 Gitflow模式，即多特性分支管理, 比如hadoop
大数据的底层hadoop框架是怎么发行的？
我们看看下图，这就一目了然了。
一个trunk主干分支，加上现行的主流版本的特性分支（branch-2.10， branch-3.2等）。
别看有trunk分支就是咬定了是trunk-based开发模式，我们要看这个产品活跃分支。
hadoop框架诞生很早，应用比较广泛，属于应用型上层框架。
很多企业用的版本都不是统一个的3.X新版本，不少企业还是2.X版本。所以hadoop社区采用这种分支管理模式，长期维护了多个主流版本的开发。这点学委觉得是非常合适的。
就像下图一样，每一个弯都是一个PR（Pull Request）：
学委想指出，这里出现了多个长分支，像feature1.x, feature
2.x(当然hadoop现在不维护1.x版本了），这个图只是展示作用。
这样的好处：
各个分支的开发独立运作，hadoop 2.X项目主要还是基于Java7运行环境执行。而hadoop 3.X 跟Java8运行。
这样提高了不同分支的独立行，兼顾发行效率。毕竟java7跟java8有不少区别的。
坏处最关键的就是：合并的风险！
随着时间发展，这些大分支积累的patch和主干分支积累的新开发特性，总需要一个时间合并起来，这时候需要很多工作进行合并校对应对一个相对大的工程。
这些大量代码合并往往需要配套不止集成测试，还有回归测试。（当然主干分支需要这套，但是主干分支可以保存每天测完，这个是多分支管理无法比拟的）
延伸 - 自己的项目该如何选择？
非常简单，如果是个人开发者，直接走TBD（Trunk Based Development）。比较简单，随时可以打一个tag，发布一个版本。
如果是一个百人团队，那么学委建议根据实际考虑了。
统一业务平台（二开或者传统大型平台）多团队多项目开发，建议走Git Flow(feature branch模式）多分支模式开发，保证各个项目团队的独立性，同时缩短定期合并的周期。
微服务多组件的单个平台，可以走TBD，划分业务的服务单元保证多个业务单元独立开发，同时分化一个核心平台组管理开发平级别需求。
思考的核心，是把平台规划好，让它支持TBD模式，避免出现大规模合并，除了开发测试成本，这个需要很大量管理介入协调！