很多人在学 Git 的时候都听说过“主干开发”这个词，但真正搞明白大公司到底用不用的，其实不多。你可能在小项目里习惯开一堆 feature 分支，合并前再提 PR，但到了上千人协作的场景，玩法就不一样了。
主干开发到底是什么
主干开发（Trunk-Based Development）简单说就是大家主要在 main 或 master 分支上提交代码，而不是长期维护多个并行分支。当然不是说不能建分支，而是分支生命周期极短，通常只存在几小时，最多一两天就合回去。
比如你在公司修一个 Bug，可能会从 main 拉个临时分支，改完测试通过，立即合并回主干。不会有“dev”、“release”这种长期存在的中间分支。
大公司真正在用吗
Google、Facebook、Microsoft 这些公司早就这么干了。Google 几乎所有代码都在一个巨型仓库里，每天成千上万次提交，靠的就是主干开发 + 强大的自动化流水线。
你可能会问：这么多人往一个分支提交，不会乱吗？关键就在于他们有一套机制。比如提交前必须跑完单元测试、静态检查，甚至性能回归测试，全部通过才能进主干。这就像地铁闸机，没刷码就是不让过。
为什么大公司偏爱主干开发
最大的好处是减少合并冲突。你在分支上拖一个月，别人也拖一个月，最后合的时候两边都改了同一个文件，解决冲突能让你怀疑人生。而主干开发要求频繁集成，每次改动小，冲突少，就算有也容易处理。
另一个关键是发布控制。主干开发不等于每次提交都上线。大公司用特性开关（Feature Flag）来控制功能可见性。代码进了主干，但默认关着，等到时机成熟，运营点个开关就上了。就像新电梯装好了，但先锁着门，哪天一开，立马可用。
小公司学得来吗
不一定非得照搬，但可以借鉴核心思路。比如缩短分支周期，别让一个功能卡三个月。再比如加强自动化测试，保证每次合并不会炸掉线上服务。
如果你团队现在还是“一发布就切 release 分支，然后各种 hotfix 往里塞”，那可以试着往主干靠一靠。先从每周一次小版本开始，每次只合经过验证的小改动，慢慢建立信心。
一段典型的提交流程
git checkout main
git pull origin main
git checkout -b fix/user-login-timeout # 创建短命分支
# 修改代码...
git add .
git commit -m "修复登录超时问题"
git push origin fix/user-login-timeout
# 在平台上提 Pull Request，触发 CI 流水线
# 审核通过，自动合并回 main整个过程可能不到半天，主干始终保持可部署状态。
主干开发不是银弹，但它确实是大公司在大规模协作下的现实选择。与其纠结“该不该用”，不如看看自己团队能不能先做到“小步快跑，频繁集成”。这才是关键。