主干开发模式下直接 push 到 main 容易出问题，因缺乏缓冲区导致构建失败、测试挂掉或兼容性破坏立即影响全员开发，必须配套快速自动化测试、小步提交、特性开关及规范提交信息。
主干开发模式下，git push 直接到 main 为什么容易出问题
不是不能推，而是推完立刻暴露风险——没有缓冲区。一旦 main 上的提交触发构建失败、测试挂掉或接口兼容性破坏，所有后续开发都会卡住。
常见错误现象包括：CI pipeline failed 卡在 PR 合并前、npm install 因依赖版本冲突失败、前端构建因未导出变量报 ReferenceError。
- 必须配套自动化测试：至少要有能跑通的单元测试 + 接口冒烟测试，且执行时间控制在 3 分钟内
- 强制要求小步提交：单次提交不应超过 200 行代码，否则难以定位问题源头
- 特性开关（
feature toggle）不是可选，是刚需：未完成逻辑必须用运行时开关包裹，避免编译通过但逻辑不可用 - 禁止直接
git commit -m "fix bug"：每次提交需关联 issue ID 或 Jira ticket，便于追溯上下文
分支开发模式中 git merge 和 git rebase 的真实取舍
二者不是风格偏好，而是协作契约的体现。git merge 保留完整历史脉络，适合多人长期协作；git rebase 重写历史，适合单人维护的短期功能分支。
容易踩的坑：rebase 后强制推送（git push --force-with-lease）会破坏他人本地分支引用，尤其当同事已基于旧 commit 做了新开发时，会导致其 git pull 出现重复提交或丢失变更。
- 团队约定优先用
merge：尤其是feature/*→develop或release/*→main -
rebase仅限个人分支内部整理：比如把 5 次临时提交压缩为 1 次语义清晰的提交，再发起 PR - 禁用
git push --force：CI 系统应配置钩子拦截，只允许--force-with-lease - 合并前必须跑通目标分支的 CI：不能只跑自己分支的测试，要确保与
main合并后仍稳定
git flow 的分支命名和生命周期管理实际有多重负担
看似规范，实则对中小团队是隐形运维成本。一个典型 feature/login 分支从创建到删除，涉及至少 4 次人工干预：拉分支、提 PR、合入 develop、合入 main 并打 tag。
真实场景中，hotfix/20260723 这类修复分支常被误操作：有人直接 push 到 main 而跳过 develop，导致下次 release 缺失该修复；也有人忘记删分支，半年后仓库里积压 87 个 feature/xxx。
-
feature/*生命周期应 ≤ 3 天：超时自动标记为 stale，CI 发邮件提醒负责人 - 禁止嵌套分支：不允许从
feature/a拉feature/a-sub，所有功能必须直出main或develop - tag 必须由 CI 自动生成：人工
git tag容易漏打或打错，应绑定 release 流水线出口 - 所有分支保护规则需启用：比如
main禁止 force push、develop需至少 1 人 approve 才能 merge
主干开发不是“不要分支”，而是把分支逻辑移到代码层
很多人误以为主干开发等于“所有人在 main 上裸写”，其实关键在于把隔离从 Git 分支转移到代码结构：用 feature toggle、canary rollout、config-driven routing 实现运行时开关，而不是靠 Git 分支做编译期隔离。
真正难的不是写开关，而是维护开关状态表。一个上线后未清理的 if (isFeatureEnabled('payment_v2'))，半年后可能变成技术债黑洞——没人记得它对应哪个需求，也不敢删。
- 开关必须带元数据：每个
toggle需声明 owner、预期下线时间、影响范围 - CI 流水线加入开关扫描：检测未注释、超期未关闭、无 owner 的开关，阻断发布
- 前端路由级开关优于组件级：避免在多个文件里散落
v-if，统一收口到 router guard - 后端开关建议用配置中心驱动：而非硬编码，便于灰度期间动态调整
git push 都像过安检——而安检背后有没有可靠的 X 光机（CI）和持证安检员（CR）。
