main分支必须始终可部署，否则CI/CD持续部署流水线将卡死；所有推送需经PR+完整CI验证，禁止直接推送；feature分支需轻量CI（lint/unit/type），hotfix须同步合并main与develop，release分支须短生命周期并及时删除。
main 分支必须始终可部署，否则 CI/CD 会卡死
持续部署（CD）流水线默认信任 main 分支的构建产物能直接上线。一旦该分支包含未测试代码、编译失败提交或配置缺失（如缺少 .env.production），自动化部署就会中断，甚至触发回滚失败。这不是“理论上不该发生”，而是实践中高频故障点。
-
main上任何一次git push都应触发完整 CI 流程：单元测试 + 集成测试 + 构建验证 + 安全扫描 - 禁止向
main直接推送；所有合并必须经由 Pull Request，且 PR 检查项（Checks）全部通过才允许合并 - 建议在 CI 脚本中显式校验关键文件是否存在，例如：
test -f dist/index.html || exit 1 - 若使用 GitHub Actions，需在 workflow 中设置
on: push: branches: [main]并确保该 job 不被跳过
feature 分支不触发部署，但必须跑基础 CI
功能分支（feature/*）本身不走 CD，但若完全跳过 CI，会导致合入 main 时暴雷——比如类型错误只在 TS 编译阶段暴露，而本地开发可能没开严格模式。
- 推荐为
feature/*设置轻量级 CI：仅运行 lint + unit test + type check，耗时控制在 2 分钟内 - 避免在 feature 分支上运行 e2e 或部署类任务，既慢又无意义
- 如果团队用自托管 runner，注意 feature 分支的 CI 不应占用生产环境凭证（如 AWS_ACCESS_KEY），防止密钥泄露
- GitHub 默认对 fork 的 PR 关闭 secrets 传递，若需测试集成能力，应改用内部分支 + draft PR 方式
hotfix 分支绕过 develop，但必须同步回 main 和 develop
紧急修复（hotfix/*）从 main 切出、修复后直接合并回 main，这是为了快速上线。但若不同时合入 develop，下次 release 会丢失该修复，造成线上有、开发环境没有的诡异状态。
- 标准操作顺序：
git checkout main→git merge hotfix/xxx→git checkout develop→git merge hotfix/xxx - 不要用
git cherry-pick替代 merge，它会破坏提交拓扑，导致后续 diff 或 bisect 失效 - CI 应检测
hotfix/*分支的合并目标：若只推到main而未同步develop，自动 comment 提醒 - 某些团队用脚本强制双合并，例如：
./scripts/hotfix-merge.sh hotfix/login-fix，封装上述两步并校验 tag
release 分支生命周期短，且不能长期存在
release/* 分支用于版本冻结和 QA 验证，不是“第二个 main”。它一旦发布完成，就必须删除，否则会干扰后续自动打 tag 和语义化版本计算。
- 典型生命周期：创建 → QA 测试 → 修复 bug（只允许 patch 级修改）→ 合并到
main打v1.2.3tag → 合并回develop→ 删除该 release 分支 - CI 可监听
release/*的 push 事件，自动启动预发布环境部署，但禁止在此分支上运行生产流量压测 - 若 release 分支存在超过 7 天，GitLab/GitHub 的 branch protection 规则应触发告警，提示人工介入
- 注意：release 分支的 commit hash 必须与
main上最终 tag 一致，否则灰度发布时无法精准比对差异
main 分支的“可部署性”不靠人盯，而要靠自动化门禁——它不是流程文档里的一句话，而是 CI 脚本里一行 exit 1 的判断。 
