feature/、bugfix/、hotfix/ 是团队约定的语义前缀，非 Git 内置语法，但决定 CI/CD 行为：feature/ 从 develop 创建并合入 develop；bugfix/ 修复测试阶段问题，合入 develop；hotfix/ 必须从 master 创建，修复后同时合入 master 和 develop。
feature/、bugfix/、hotfix/ 这些前缀到底代表什么
它们不是 Git 内置语法，只是团队约定的语义标签。Git 本身只认分支名字符串，feature/login 和 xyz123 对它完全等价。但加前缀后，人和自动化系统（CI/CD、权限网关、PR 模板）就能立刻识别意图。
关键区别在触发时机和影响范围：
-
feature/：基于develop创建，目标合入develop；不直接碰master，也不处理线上问题 -
bugfix/：开发或测试阶段发现的问题，仍走develop流程；修复后合入develop，后续随 release 流转 -
hotfix/：必须从master拉出，修复后**同时合入master和develop**；跳过测试分支直发生产是常见错误
release/ 和 test/ 分支不能混用
release/ 是冻结分支：功能已封版，只允许修小 bug、改文案、打 tag。CI 系统常据此自动构建预发布包、触发 UAT 流程。
test/ 是环境对应分支，通常长期存在、持续集成，用于日常冒烟测试。它不参与版本冻结，也不打正式 tag。
容易踩的坑：
- 把
test当release用——导致紧急 hotfix 被漏合进下个 release - 在
release/上新增功能或重构——破坏“冻结”语义，让 QA 失去信任 - 命名写成
release-test或test-release——既不符合前缀规范，又让自动化脚本无法识别类型
refactor/、docs/、chore/ 这类前缀为什么不能省略
它们区分的是「是否变更运行时行为」。CI/CD 流水线会根据前缀决定是否跑全量测试、是否触发部署、是否需要 Code Review 强制通过。
Cnb Cool Git
下载
CNB 云原生构建平台的 Git 操作技能，支持代码克隆、提交、推送、分支管理、Merge Request 管理、流水线触发与结果读取。初次使用需收集用户的 Git 用户名和邮箱。
比如：
-
refactor/user-service-cleanup：可能动了核心逻辑，需跑全部单元+集成测试 -
docs/api-reference-update：只改 Markdown，跳过编译和测试，只走文档发布流程 -
chore/upgrade-node-20：依赖升级，可能影响构建环境，需单独验证 CI 工具链兼容性
省略前缀（如直接叫 user-service-cleanup）会让系统误判为普通功能分支，浪费资源或漏掉关键检查。
Jira 编号要不要放、放哪、怎么放
必须放，且放在前缀之后、描述之前，格式统一为 feature/JIRA-123-login-flow。不是 feature/login-flow-JIRA-123，也不是 feature/JIRA-123（太泛）。
原因很实际：
- Git 日志里能直接关联到需求上下文，
git log --oneline就能看到 Jira ID - CI 构建失败时，报错日志自动带链接跳转到对应 issue
- 分支清理脚本可按 Jira 状态（Done/Closed）自动归档，避免堆积
长度控制要严格：Jira 编号 + 前缀 + 描述总长 ≤ 32 字符（Git 服务器和 GitHub UI 对超长分支名支持不稳定），feature/JIRA-1234567890-long-desc 这种就容易被截断或拒绝创建。
