Git分支前缀（feature/、bugfix/、hotfix/）严格决定CI/CD行为、权限控制与PR模板；必须全小写、连字符分隔、含Jira编号（前置）、长度≤32字符；release/分支仅限语义化版本或-test后缀临时分支。
feature/、bugfix/、hotfix/ 这些前缀不是随便写的
Git 分支前缀直接决定 CI/CD 行为、自动化清理策略、权限控制逻辑，甚至影响 PR 模板自动填充内容。比如 git checkout -b feature/login-ui 创建的分支，CI 系统可能默认只部署到 dev 环境；而 git checkout -b hotfix/payment-fail 触发的流水线会跳过部分测试，直接构建并推送到预发环境。
常见错误是把 fix/ 或 dev/ 当作前缀用——这些不被主流工具链识别，Jenkins 插件、GitLab Auto DevOps、GitHub Actions 的 branch filter 都会忽略它们。必须严格使用团队约定的前缀集合，且全小写、无空格、无下划线。
-
feature/：仅用于尚未上线的新功能，必须从develop（或main）检出，完成后只合入develop -
bugfix/：用于修复测试阶段发现的问题，从develop检出，修复后合入develop；若问题来自 release 分支，则应从release/xxx检出并合回该 release 分支 -
hotfix/：仅限线上main分支已发布版本中暴露出的紧急缺陷，必须从main检出，修复后同时合入main和develop
分支名里带 Jira 编号不是可选项，是强约束
像 feature/MATERIAL-123-add-search 这类命名，不是为了“看起来专业”，而是让 Git 提交记录能自动关联需求系统。CI 流水线在构建时会解析分支名中的 MATERIAL-123，自动拉取该 ticket 的描述、优先级、负责人，用于生成发布说明和告警分级。
漏掉编号最直接的后果是：PR 合并后，Jira 中该 ticket 无法自动标记为 “In Review” 或 “Done”；更隐蔽的问题是，审计时无法追溯某次线上变更对应哪个原始需求，尤其在合规检查或事故复盘中会卡住流程。
- 编号必须前置，不能放在末尾，否则正则匹配失败：
feature/add-search-MATERIAL-123❌ - 多个 ticket 关联时，只取主 ticket 编号，不拼接：
feature/MATERIAL-123-and-456❌，应选主导需求编号 - 编号格式需与 Jira 实例一致（如
PROJ-789），大小写敏感，不能简写为789
release/v1.2.0 和 release/material-add 是两类完全不同的分支
release/ 前缀分支本质是“发布窗口”，不是“功能集合”。前者 release/v1.2.0 是语义化版本号，用于冻结代码、打 tag、走上线审批流；后者 release/material-add 是业务描述型命名，实际用途是临时集成测试分支，生命周期极短，测试完即删。
混淆这两者会导致发布流程断裂：如果用 release/material-add 直接推到生产环境，CI 工具无法识别其为正式发布分支，不会触发版本归档、Changelog 生成、Docker 镜像打标等动作；反过来，若把 release/v1.2.0 当作日常开发分支长期存在，会阻塞后续 release 分支创建（GitLab 默认禁止同名分支重复创建）。
- 正式发布分支必须含
vX.Y.Z格式，且只能由 Release Manager 创建 - 集成测试分支若必须用
release/前缀，需加-test后缀，如release/material-add-test，并在 README.md 中明确标注非正式分支 - 所有
release/分支都必须在合并后 24 小时内删除，避免残留
连字符分隔、全小写、长度 ≤ 32 字符 —— 这些限制来自底层工具链
不是风格偏好，是硬性兼容要求。Git 本身允许路径中含空格和大写，但 Jenkins 的 SCM 插件、GitLab Runner 的 shell 执行器、Kubernetes Helm Chart 的 values.yaml 引用逻辑，都会在遇到 FeatureLoginUI 或 feature/login ui 时静默失败或解析错乱。
最常被忽略的是长度限制：feature/enable-real-time-notification-for-user-profile-with-a11y-support 看似清晰，但超长分支名会导致 GitHub API 返回 414 错误（URI Too Long），GitLab 页面加载卡死，Docker build context 构建失败。
- 推荐最大长度 32 字符，含前缀和斜杠（
feature/占 8 位，剩 24 位给描述） - 用连字符替代空格和下划线：
feature/user-profile-notifications✅，feature/user_profile_notifications❌ - 避免缩写歧义：用
auth而非au，用ui而非int（interface 易混淆为 integration）
git checkout -b 时，得想清楚这个分支接下来要走哪条自动化流水线、会被哪些系统消费、生命周期多长——名字一旦 push 到远程，就不再是个人习惯问题了。 
