git分支命名是ci/cd流程能否自动执行的关键，必须严格遵循规范：feature/、bugfix/、hotfix/等前缀全小写且正则匹配；jira编号前置、大小写敏感；release/分支须为语义化版本或-test后缀；命名错误将导致流水线失效、环境错发或发布失败。
Git多人协作中，分支命名不是风格问题，而是流程能否自动跑通的关键。不按规范起名，CI/CD流水线可能跳过测试、PR模板填错字段、Jira状态无法同步，甚至导致hotfix没推到生产环境。
feature/ 开头的分支必须带 Jira 编号且前置
像 feature/user-login 这种命名在小团队能凑合，但一旦接入 CI/CD 或 Jira 集成，就会失效。系统靠正则匹配编号，如果编号不在开头，解析失败。
-
feature/PROJ-123-login-ui✅ 可被识别，触发 dev 环境部署 + 自动关联 ticket -
feature/login-ui-PROJ-123❌ 编号在末尾，CI 忽略，Jira 不更新状态 -
feature/login❌ 无编号，审计时无法追溯变更来源 - 多个需求关联时只取主编号：
feature/PROJ-123-and-456❌ 应为feature/PROJ-123-login-refactor
hotfix/ 和 bugfix/ 的检出源与合并目标完全不同
名字只差一个字母，行为却完全相反：一个是线上救火，一个是在测试阶段修漏网 bug。混用会导致代码漏合、环境错发。
openclaw-gitcode-pr-monitor
下载
监控一个或多个 GitCode 仓库的 PR，通过 OpenClaw Gateway 自动执行 AI 审查，发布 PR 评论，并发送钉钉和企业微信通知。
-
hotfix/分支必须从main检出，修复后同时合并回main和develop -
bugfix/分支只能从develop检出，修复后只合入develop - 用
fix/或patch/前缀 —— 主流 CI 工具（GitLab Auto DevOps、GitHub Actions branch filter）默认不识别，流水线不会触发 - 误从
develop拉hotfix/xxx：修复代码进不了main，线上 bug 依然存在
release/ 分支名必须是语义化版本或 -test 后缀
release/ 不是“功能集合”标签，而是发布窗口标识。命名不对，上线审批流会卡住，tag 打不上，自动化发布失败。
-
release/v2.1.0✅ 符合 semver，可触发冻结、打 tag、走发布审批 -
release/login-feature❌ 工具链无法识别，会被当作普通分支忽略 -
release/v2.1.0-test✅ 允许的临时变体，用于预发验证 -
release/202606❌ 数字型版本不被语义化工具接受，npm version、standard-version等会报错
真正容易被忽略的不是“该用什么前缀”，而是分支名一旦提交到远程，就参与自动化决策——它不是给人看的，是给机器读的。少一个 -、多一个空格、Jira 编号大小写错，都可能让整条流水线静默失败。
