公司新项目刚启动，团队决定用主干开发模式，说是为了快速迭代、减少合并冲突。可没过两周，代码库就乱成一锅粥，天天有人提交后导致构建失败，测试环境跑不起来，安装包打不出来。开发抱怨，运维头疼，产品经理在群里疯狂@人问怎么还不能装。
分支策略搞错了，主干成了公共垃圾桶
很多人以为主干开发就是所有人直接往 main 分支上提代码。于是张三的功能还没测完，李四的接口改了一半，王五顺手修了个紧急 bug，全挤在一起提交。结果呢？新拉的安装包一运行就报错，日志里全是找不到模块、配置冲突的问题。
主干开发不是不要分支，而是要短生命周期的特性分支。正确的做法是：
git checkout main
git pull origin main
git checkout -b feature/user-login-20240401
# 开发完成后合并回主干缺少自动化流水线，靠人肉检查走流程
有个团队坚持“人工 Code Review 合并”，每次提交都要等两个同事点头。结果白天没人理，晚上集中处理，一合并就是十几个变更堆一块儿，CI 直接爆红。第二天早上，新版本装不上，客户等着演示，临时切回旧版本，现场出丑。
主干开发必须搭配 CI/CD 自动化。每次提交触发构建和基础测试，通不过的代码根本进不了主干。比如用 GitHub Actions 配置：
name: Build and Test
on: [push]
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- run: npm install
- run: npm run build
- run: npm test环境配置不统一，本地能跑线上炸锅
小刘在自己电脑上开发，Node 版本是 18，依赖全用 npm 安装。他提交后 CI 用的是 Node 16，某些包直接装不上。构建失败，安装脚本卡住，运维没法部署。
这种问题太常见。解决方案是锁定环境配置。用 .nvmrc 指定 Node 版本，用 package-lock.json 锁死依赖版本，甚至用 Docker 统一构建环境：
FROM node:16-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build
EXPOSE 3000
CMD ["npm", "start"]没有灰度发布机制，一出事就是全线崩溃
主干开发意味着频繁上线，但如果你的发布是一把梭哈——新版本推全量，那风险太大。曾经有个项目，一次提交引入了内存泄漏，凌晨发布后，早上全员打开软件就卡死，重装都救不回来。
得有降级手段。比如通过功能开关（Feature Flag）控制新逻辑是否生效，哪怕代码上了主干，也能在配置里关掉。或者用渐进式交付，先让 10% 的用户装上新版本，观察没问题再推全。
主干开发不是谁都能玩得转的。它要求团队有严格的提交纪律、自动化的保障体系、一致的环境管理和灵活的发布策略。否则，所谓的高效迭代，最后只会变成高频翻车。