在掘金搜索了一下, 很少看到有关 trunk base 开发流程的文章，其实我所在的团队应用 trunk base 开发流程已经有了很长时间，并且从这种流程中获得了实实在在的好处。所以写下这篇文分享下。
首先， 需要申明一下
Google does Trunk-Based Development and have 35000 developers and QA automators in that single trunk, that in their case can expand or contract to suit the developer in question.
Google 采用基于主干的开发模式，拥有 35000 名开发人员和自动化质量保证人员在同一个主干上工作。在他们的案例中，这个主干可以根据具体的开发人员的需求进行扩展或收缩。
引
您是否遇到过以下问题？
- 我刚实现了一个很厉害的功能... 什么 你也实现了？我怎么从来没看到过哇？哦... 在你的开发分支啊。那怎么办 用你的还是用我的？
- 这周 PM 给了三个 P0 需求， 我不吃饭也做不完啊... 为什么不分给同事做？他根本不了解这个的上下文... 如果某个没有主注意到的边界出了问题... 锅还是要我来背.
- 双十一 code freeze 了， 11 月只有一个发板日期，现在有三个需求需要周四上线，大家互相看看对方几千行的 MR， 都希望早点合了自己的让别人 rebase ...
坦白的说，这意味着不论是开发者还是开发团队，都在当前的开发流程中遇到了问题，如果这些问题频繁出现，不妨阅读本文或 官方文档 了解 trunk base.
为什么我们会选择 trunk base
这其实是一个很好回答的问题。
很久以前，组内也是使用 git flow 流程进行开发的。每一个人都有自己的一摊东西，由于代码重合度很低，几乎很少有 merge conflict 事件发生。但是这也带来了 问题 1： 由于许多人只关心自己的业务，有时候他们就会非常忙，有时候就会非常闲。
灾难在某一天降临了， 当业务需求增多，复杂度增大，尤其是许多不得不修改其他人 scope 下代码来达成自己目的的业务越来越多，几乎每一天都能听到有人在抱怨合并冲突。这也就是 问题 2： 如果短时间内出现大量需求， 那么合并冲突就不可避免。
于是，我们开始思考， 能不能有一种方法， 既能保证大家工作量均匀，又可以不让解决冲突所花费的时间甚至比开发还要久呢？
敏捷 敏捷 还是___敏捷
是的， 讲到这里，答案已经很明显了，我们需要拥抱敏捷开发，但是请注意：敏捷开发 !== 加班开发， 并不是只要看起来花了更少的时间就是敏捷开发。我们需要的是一套方法论，如何从流程上避免问题的发生。
trunk base 解决了这个问题，让我先来介绍一下这个流程， 再讲一下我们的具体实践和对他的改良。
Trunk base development
官方文档中这样介绍 trunk base 开发流程
A source-control branching model, where developers collaborate on code in a single branch called 'trunk', resist any pressure to create other long-lived development branches by employing documented techniques. They therefore avoid merge hell, do not break the build, and live happily ever after.
一种源代码控制分支模型，开发人员在一个名为"主干"的单一分支上协作编写代码，通过采用记录好的技术来抵制创建其他长期存在的开发分支的压力。因此，他们避免了合并地狱，不会破坏构建，并且从此过上了幸福的生活。
是的， trunk base 开发流程通过将 MR 分解为许多非常小的 MR, 并尽快将他们合并到 master 分支来避免合并冲突。
他将流程从这样：
变成了这样
另一个好处是：这种开发流程在另一个方面提升了代码质量。
有这样一个场景，你的实习生花费了一周时间提交了一个长达 1200 行的 MR，你观测到了十几个需要改进的点，有一些很大，有一些很小。你细心的一一指出，于是 又过去了三天，他进行了修改，但是由于修改， 现在又产生了五个以上的需要改进的点。
这种时候，你可能只会指出最明显需要改进的那几个点，而忽略掉一些微小的问题。因为明显时间已经不太够了。但是问题没有消失，依然存在。过了几个月你修改这部分代码时突然觉得逻辑不太对，一查 git 记录是自己 merge 的。你想改动一下逻辑，但是又几乎忘掉了当时的业务逻辑，很有可能，你会放弃这次修改，并且让这个奇怪的逻辑一直留在代码中，直到永远。
其实，修改一个巨大的 MR， 无论对开发者还是 reviewer 都是巨大的挑战，如果把代码长度限制在 80-200 行，情况会好得多。
在应用了 trunk base 开发流程后，你可以将 task 切分为更小的 sub-task, 将一些与上下文关系较小, 且可以并行的 sub-task 抽出， 分配给不熟悉业务的同学来做。当然，我也必须要承担其他人分配给我的 sub-task。
慢慢的，大家对业务都很熟悉了。那么其实也不会因为一个业务上 task 太多导致加班加到吐血了。因为每个人都可以快速的进入开发状态。
Trunk Base 存在的问题以及对它的改良
看起来，trunk base 完美解决了合并冲突与团队成员工作量在某一段时间激增的问题。但是请注意，天下是不会有完全免费的午餐的。使用这种开发模式一样会带来一些问题。
- 提交每一个 chunk 都会新建一个分支，如果合并不及时，那就会变成 c 分支依赖 b 分支依赖 a 分支。反倒没有把所有代码都放到一个 branch 的效率高。
- 所有代码都会立刻合并到 master 分支，如果里面含有 bug, 那么可能导致主分支立刻崩溃。如果恰巧你们使用了 monorepo, 那么其他 team 的同学可能一脸懵逼的发现调试模式都打不开了。
- 开发同学会开始抱怨从需要保证一个 feature branch 代码没有 bug, 到保证每一个 commit 没有 bug, 压力比以前大了很多。
针对这几个问题，我所在的团队做了一些优化：
- 针对问题 1, 我们制作了一个 chatbot, 如果一个 MR 6 小时和 24 小时内仍然没有被合并，bot 会发送 review 提醒，其实，大部分 MR 都不会触发 bot 的提示，这是因为由于代码行数较小。几乎所有的 MR 都可以在半天之内修改完毕。
- 针对问题 2， 我们使用了 feature toggle， 关于这个技术可以阅读 这个文章。简而言之，它使得我们更加放心的开发新的 feature.
- 针对问题 3, 这其实是一个取舍。当然，开发同学会不得不更小心的编写代码。但另一方面，它加快了我们定位问题的速度，我们不再需要排查全部的 commit, 我们可以通过迅速的回滚最近合并的一小段代码或关闭新 feature 的 toggle 快速解决问题。这相对于只能立刻合并一个 Fix 并紧急发布到线上的做法，要方便的多。
结
总而言之，当团队适应了这种开发模式，我们保持了连续一年半没有出现 p1 以上 bug, 研发效率显著提升，并满足了同学们同时接触多种业务的需求。 review 也从一潭死水变成了高度活跃，最终，即使离开的同学也会因为比较优秀的代码风格获得更好的工作机会。