主干开发不是“硬扛”，是让协作变轻松的日常习惯

上周五下午，团队又卡在了发布前的合并冲突上。小王改了登录页样式，小李优化了用户权限逻辑，两人各自在本地跑通了，一推到 main 分支——直接红了。这不是偶然，是主干开发没跑顺的真实切片。

主干开发，不是把所有人塞进一条窄道

很多人一听“主干开发”（Trunk-Based Development，TBD），下意识觉得：每天往 main 上推？那不是天天打架？其实恰恰相反，它不是逼你“猛推”，而是倒逼出一套轻量、高频、可预期的协作节奏。我们团队从每月一次大合并在 GitLab 上吵三天，到现在平均每人每天提交 2~3 次，main 分支常年绿着，靠的不是神仙队友，是一些具体到手指头的操作习惯。

每天早上第一件事：拉最新，跑测试，再写代码

不等“我这个功能做完再同步”，而是把“同步”变成呼吸一样的动作。我们用一条 shell 别名：

alias up='git pull origin main && npm test'

早上打开 IDE，敲 up，看终端绿色通过，才开始动键盘。哪怕只改一行文案，也先确保自己站在最新的主干上。这招省掉了 80% 的“咦我本地怎么没问题？”类问题。

小步提交，带明确意图

拒绝“fix bug”“调整一下”。我们约定：每次提交信息必须能回答“为什么改”和“影响哪块”。比如：

git commit -m "login: add email format validation before submit"

而不是

git commit -m "修复登录问题"

这样，当 CI 报错时，一眼扫过去就能定位是谁动了 login 相关逻辑，不用翻两天记录。

功能开关（Feature Flag）是主干开发的缓冲垫

新模块还没测完？没关系，先合进去，但用开关包住：

if (featureFlags.enableNewDashboard) {
  renderNewDashboard();
} else {
  renderLegacyDashboard();
}

上线后通过后台一键关闭，不影响其他功能走查。我们用的是自研的轻量 flag 管理器，配置项存 JSON 文件里，前端启动时加载，不依赖后端接口，连本地调试都零延迟。

办公软件场景里的真实映射

别以为主干开发只属于写后端的人。用 Figma 做 UI 协作时，我们也照搬这套逻辑：设计稿不建“v1_final_really_final”分支，而是所有修改直推 main 页面，靠版本历史 + 评论锚点追踪改动；用 Notion 管需求池时，每个卡片标题写清变更范围（如“注册页-手机号校验逻辑调整”），避免多人同时编辑同一区块导致覆盖；就连共享 Excel 表格，运营同事也学会了拆成“数据源表”和“看板表”，后者用公式引用前者，源头一更新，全组视图自动刷新——这本质就是主干+消费层解耦。

主干开发不是教条，是把“别乱动别人代码”这种模糊提醒，转化成“我拉了最新再动”“我加了开关再合”“我写了能读的提交信息”这些手边可执行的动作。它不消灭冲突，但让冲突变得短、小、好定位。就像每天整理桌面，不是为了拍照发朋友圈，而是下次找笔的时候，3 秒内摸到。