Git工作流折腾了两年，最后还是trunk-based用着最舒服

Git 工作流折腾了两年，最后还是 trunk-based 用着最舒服

最开始写代码那会儿，我压根没想过 Git 工作流还能有什么讲究。一个人开发嘛，master 上直接 push，出问题了回滚完事。简单粗暴，但也够用。

后来团队慢慢扩大到五六个人，问题就来了。你改你的模块，我动我的逻辑，合代码的时候天天冲突。那段时间我最怕听到的就是："你 pull 一下最新代码再 merge。"

唉，说到这个就来气。于是我开始研究各种 Git 工作流。

先试了 Git Flow，太重了

Git Flow 应该是最出名的工作流了吧。master、develop、feature、release、hotfix 五条分支。听起来很完美对不对？每个分支各司其职，井井有条。

实际用起来呢？我们一周就快疯了。每次开发一个新功能，要建 feature 分支，开发完合并到 develop，等攒够了再合到 release，最后才上 master。这还只是日常开发。对于一个小团队来说，工作量直接翻倍。

最要命的是修线上 Bug。按 Git Flow 的规矩，hotfix 要从 master 拉，修完再合并回 master 和 develop。但我们的 develop 比 master 超前了一大截，每次 hotfix 合并回去都要解决一堆冲突。有一次半夜修了个紧急 Bug，光合并冲突花了半小时。我坐在电脑前面，气得想砸键盘。

也不能说 Git Flow 不好。真的。大型项目、多版本并行、严格发布流程——这些场景下它确实能撑住场面。但我们这种小团队嘛，大炮打蚊子。

换 GitHub Flow，又太随意了

Git Flow 搞累了，我们换了 GitHub Flow。模式很简单：从 master 拉分支，改完提 PR，Code Review 通过后合并回 master，直接部署。

刚开始还是很爽的。流程轻了，开发节奏明显快了。但好景不长——我们发现 master 太脆弱了。

有次同事往 master 合了一个改动，线上页面白屏了五分钟。原因？PR 没经过充分测试，Review 也就扫了一眼。这事发生过几次之后，大家对合并都变得小心翼翼。结果呢，反而拖慢了速度。

GitHub Flow 的问题在于：它假设每次 PR 都是经过充分测试和 Review 的。但现实不是这样的。没有人能在本地把全量测试跑完再提 PR，也没有人能通过 Code Review 发现所有问题。

最后试了 GitLab Flow，有些改善

GitLab Flow 算是前两种的折中方案。它引入了环境分支的概念——master、pre-production、production 三级。feature 分支合到 master 后，先部署到预发布环境验证，没问题再合并到 production。

这个流程我们用了三个多月，确实比 Git Flow 轻，又比 GitHub Flow 稳。但用久了还是觉得哪里不对。

最大的问题是：环境分支之间的同步总让人提心吊胆。今天有人往 master 合了一个改动，明天又有人往 production 做了 hotfix，过两天发现两个分支差了一截，合起来又是一场灾难。

终于换成了 trunk-based，回不去了

Trunk-based 的核心思想就一句话：所有人都在主干分支上开发，频繁提交，提交即部署。

刚听到这个方案的时候，我第一反应是："疯了吧？那不完蛋了？"

但深入了解之后才发现，trunk-based 要的不是"莽"，是配套措施到位：

第一，必须要有完善的自动化测试。提交之前本地跑一遍单元测试，CI 自动跑集成测试，测试不通过不允许合并。

第二，必须要有功能开关（Feature Flag）。不完整的功能用开关隐藏起来，不影响线上用户。这样就不会出现半成品代码上线的问题。

第三，提交必须小。一个功能拆成多个小提交，每次提交只改几十行代码。改动越小，出问题的概率越低，出了问题也容易回滚。

我们按这个方案改造了工作流，效果非常明显。以前合一次大 PR 要花半天时间解决冲突，现在每次只提交少量改动，几乎没什么冲突。以前修个 Bug 要等部署窗口，现在修完直接合并、CI 跑完就自动上线了。

唯一要适应的就是习惯改变。以前开发一个功能可以埋头写三天再提 PR，现在必须把它拆成若干个可独立工作的小块，每完成一小块就提交一次。

说点实用的经验

如果你也在考虑切换工作流，我建议先别急着一步到位。可以先做这几件事：

先把 CI/CD 搭好。不管你用什么工作流，没有自动化测试和部署，都是白搭。这是基础设施，必须优先搞定。

再引入 Feature Flag。不用什么复杂的开关系统，一个简单的配置中心或者环境变量就够了。关键是养成习惯——不完整的功能默认隐藏。

最后才是改流程。从小团队开始试点，跑一两个月再铺开。

说到底，工作流只是工具。Git Flow 有 Git Flow 的适用场景，trunk-based 有 trunk-based 的好处。适合自己团队的才是最好的。但如果你问我个人的感受——折腾了两年各种方案之后，trunk-based 是真的省心。