main分支不能直接push，因其受保护以确保随时可部署，所有变更须经合并请求触发CI流水线和至少两次人工审查。
main分支为什么不能直接push
因为直接推送会绕过质量门禁，main分支必须保持随时可部署状态。所有代码变更必须走合并请求（MR/PR），强制触发CI流水线和至少2次人工审查。
常见错误现象：remote: error: GH006: Protected branch update failed —— 这不是权限问题，是分支保护规则生效的正常拦截。
- GitHub/GitLab默认启用
Require pull request reviews before merging和Require status checks to pass before merging - Open-AutoGLM平台额外要求
enforce_admins: true，管理员也不能豁免 - 如果CI检查失败（比如
test/unit或lint未通过），PR界面会显示红色×，无法点击Merge按钮
release分支如何冻结功能并完成发布
release分支不是“写完就发”，而是进入预发布验证期：只允许修复测试中暴露的问题，禁止新增功能或重构。
典型操作路径：
- 从
develop拉出release/v2.3.0分支 - 团队在该分支上跑完整回归测试、性能压测、安全扫描
- 发现bug后，只在
release/v2.3.0上提交修复，不回退到feature/*分支改 - 验证通过后，先合并到
main，再打tag：git tag -a v2.3.0 -m "Release v2.3.0" - 最后把修复同步回
develop，避免遗漏
容易踩的坑：git merge --no-ff release/v2.3.0必须在main和develop两个分支上分别执行，漏掉develop会导致下个迭代缺失热修复。
hotfix分支怎么避免污染develop主线
hotfix分支从main拉出，修复完成后必须双路合并：既进main（立即上线），也进develop（防止下次发布重复出问题）。
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
错误做法：只合并到main，然后手动在develop里重写一遍修复逻辑——这会引入不一致风险。
- 正确命令序列：
git checkout main && git merge hotfix/BUG-1234-login-timeout，再git checkout develop && git merge hotfix/BUG-1234-login-timeout - 如果hotfix涉及数据库迁移，需额外确认
develop环境是否已适配，否则可能引发本地启动失败 - hotfix分支命名必须带
BUG-前缀且关联Jira ID，否则CI流水线会拒绝触发构建
自动化分支流转依赖哪些关键配置
自动化流转不是靠脚本“自动merge”，而是靠CI/CD流水线识别分支名语义，触发对应动作。核心在于分支命名+GitHub Actions规则匹配。
例如，当推送release/v*分支时，CI会自动：
- 运行全量测试套件
- 生成镜像并推送到
registry.example.com/open-autoglm:v2.3.0 - 更新CHANGELOG.md并提交回该release分支
关键配置文件位置：.github/workflows/release.yml，其中on.push.branches字段必须包含release/**模式。漏配会导致release分支推送后无任何反应，只能人工干预。
最易被忽略的点：release分支上的提交必须全部带conventional commits前缀（如fix:、feat:），否则CHANGELOG生成失败，CI会中断流程。
