主干开发踩过的坑，我们团队是怎么挺过来的

上周代码又崩了，不是线上出问题，是本地连 git pull 都卡在冲突里半天——同事小李盯着终端发呆，我端着咖啡路过，顺手看了眼他的分支名：feature/user-center-v3-refactor-20240415-fix。这名字我都背下来了，但主干上早没人记得它。

主干不是“别人的事”

刚切到主干开发那会儿，我们以为只是换了个 merge 方式：以前等 PR 过完再合，现在直接 push 到 main。结果第一周就翻车——三人同时改同一个配置文件，git status 一跑全是红色，git add -A 后 commit message 写的是“修复登录态”，其实只调了两行 token 刷新逻辑，却把另两个人的埋点字段覆盖掉了。

后来我们定了条土规矩：每天早十点，所有人先 git pull --rebase origin/main，哪怕没动代码也拉一下。不是为了仪式感，是怕某人本地积压三天改动，一推直接把 CI 流水线堵死。

小步快跑，比“做完再交”管用

有个同事习惯憋大招，一个用户导出功能写了两周，本地测得飞起，推上去才发现主干上周加了权限中间件，他所有接口全 403。现在他改成每天至少一次 push，哪怕只提交一行日志打印：

console.log("[export] start");

不是为了凑数，是让 CI 先跑通基础环境，也让其他人知道“导出模块正在动工”。

我们还在 main 分支开了个 .wip 目录，放临时调试脚本、半成品组件，不参与构建，但能随时被看到。有人想复用某个数据处理逻辑，进去抄两行就走，不用再问“你那个导出的工具类在哪？”

别信“稳定分支”，信自动化

有次上线前，QA 发现列表页空白，查了半天是主干里某人提交了一个未 export 的 React Hook，本地没问题，CI 构建时 tree-shaking 把它干掉了。后来我们在 package.json 的 prepare 脚本里加了检查：

grep -r "export.*use" src/ | grep -v ".test." || echo "⚠️ 检测到未导出的自定义 Hook，请确认是否遗漏 export"

CI 失败比线上报错便宜多了。

主干开发不是靠人盯，是靠每行代码过流水线。我们删掉了 develop 分支，main 就是唯一真相源。谁改坏了，所有人立刻感知——因为下一秒 build 就红了，而不是等周五下午打包才发现。

现在团队晨会第一句常是：“main 上谁刚推了？我拉一下。” 没人再问“这个功能合并了吗”，因为答案永远只有一个：看 main 的最新 commit。