feature分支不要加环境前缀，它只应从develop拉出、合并回develop，生命周期内不参与部署；加dev/或test/前缀会混淆语义、误导ci触发错误构建。
feature分支要不要加环境前缀
不要。feature分支本质是开发阶段产物，不对应任何部署环境，加dev/或test/这类前缀反而混淆语义。它只该从develop拉出、合并回develop，生命周期内不参与环境部署流程。
常见错误：写成dev/feature/login或test/user-profile——这会让CI脚本误判为环境专用分支，触发不该有的构建任务；也容易让新人以为该分支要部署到对应环境。
- 正确做法：统一用
feature/xxx，如feature/payment-integration - 若需区分开发归属，可用
feature/xxx-john（开发者缩写），但非强制 - 环境信息应由CI/CD流水线根据分支类型自动注入，而非编码进分支名
release和hotfix分支如何体现环境意图
release和hotfix是唯二需要明确关联环境的临时分支，但不是靠前缀，而是靠创建来源和合并目标来定义环境语义：
Conventional Git
下载
Conventional Commits v1.0.0 分支、工作树命名及提交信息规范，适用于 GitHub 与 GitLab 项目，用于创建分支和命名工作树等场景。
-
release/v1.2.0必须从develop创建，最终合并到main并打v1.2.0tag——它天然对应UAT环境验证，无需写uat/release -
hotfix/login-crash-202607必须从main创建，修复后同时合入main和develop——它代表对PRO环境的紧急干预，名称里带日期或issue号即可，不用prod/hotfix - 强行加环境前缀（如
uat/release-1.2）会破坏Gitflow工具链识别，GitHub Actions等默认不认这种变体
哪些分支名会触发CI自动部署到特定环境
CI系统通常只监听固定命名模式，不是所有带环境词的分支都会被识别：
- 被识别为UAT部署分支：仅
release（无后缀）或release/*，例如release、release/v2.0.0 - 被识别为PRO部署分支：仅
main或master（取决于团队约定），hotfix/*不会自动部署，需人工触发 - 被识别为FAT部署分支：仅
develop，部分团队也支持test（固定名），但test/xxx或fat/xxx无效 -
staging、preprod等名称在多数CI中无默认行为，除非团队显式配置了匹配规则
环境标识混入分支名的典型坑
把环境缩写硬塞进分支名，最常导致三类问题：
- Git命令失效：
git checkout preprod/feature会被解析为路径preprod/feature而非分支名，尤其在旧版Git中报错pathspec 'preprod/feature' did not match any file(s) - 分支列表混乱：不同人写
uat/xxx、pre/xxx、staging/xxx，无法用git branch --list "uat/*"统一筛选 - 权限策略失效：企业级Git平台（如GitLab）的分支保护规则按正则匹配，
^release/.*$能保护所有发布分支，但^uat/.*$和^preprod/.*$就得分别配置
环境归属应该由分支类型决定，而不是靠名字里塞关键词——这是多数团队踩过坑后回归的共识。
