远程分支名必须严格遵循团队规范，因ci/cd、pr模板、权限系统等均依赖其前缀（如feature/）和jira编号（如material-123）进行自动化匹配与流程控制，命名错误将导致静默失败或流程错乱。
远程分支名本身没有 Git 强制规范，但团队协作中必须与本地分支命名规则对齐，否则 CI/CD、权限系统、PR 自动化会全部失效。
为什么 origin/feature/login-ui 不等于 origin/feat-login-ui
远程分支名是 origin/feature/login-ui 这种形式，其中 feature/login-ui 是远程仓库上真实存在的分支名。Git 本身不校验这部分，但所有自动化工具（Jenkins、GitLab CI、GitHub Actions）都靠正则匹配 feature/、bugfix/ 等前缀触发对应流水线。如果本地误建了 feat-login-ui，推送到远程后变成 origin/feat-login-ui，CI 就不会识别——它根本不会运行，也不会报错，只会静默跳过构建。
- CI 配置通常写死匹配
^feature/.*$，feat-不符合，直接忽略 - PR 模板靠分支前缀自动填充「影响环境」「是否需回滚」等字段，错位就填空
- GitLab 的 protected branches 规则按前缀配置权限，
feat-分支可能被允许直接 push 到远程，而feature/被强制 require approval
git push 时远程分支名怎么生成
你执行 git push origin feature/login-ui，远程分支名就是 feature/login-ui；执行 git push origin main:dev，远程分支名就是 dev——它完全由冒号右边的名称决定，和本地分支名无关。
- 本地分支叫
login-feature，但用git push origin login-feature:feature/login-ui，远程创建的就是feature/login-ui - 别依赖
git push -u自动推导：如果本地分支名不合规（比如dev/login），-u会把错误名字原样推到远程 - 检查远程分支真实名称，用
git ls-remote --heads origin，而不是只看git branch -r（后者显示的是本地远程跟踪引用，可能已过期）
远程分支名含 Jira 编号是硬性要求
不是“建议”，是 CI 流水线解析分支名提取 MATERIAL-123 的唯一依据。漏掉或放错位置，Jira ticket 就无法自动更新状态，发布说明里也拿不到需求上下文。
- 必须前置：
feature/MATERIAL-123-login✅，feature/login-MATERIAL-123❌（正则feature/([A-Z]+-\d+)-匹配失败） - 大小写敏感：
material-123或Mat-123都不会被识别 - 多个关联 ticket 时，只取主导编号，不拼接：
feature/MATERIAL-123-and-456❌，应为feature/MATERIAL-123-login-refactor
release/ 分支命名不能混用语义化版本和业务描述
release/v2.1.0 和 release/order-integration 在团队流程中代表完全不同生命周期的分支，远程名写错会导致审批流卡死或自动清理误删。
-
release/v2.1.0：走上线审批、打 tag、冻结代码，CI 会自动触发部署到 prod 并锁分支 -
release/order-integration：临时集成测试分支，CI 只部署到 staging，且git remote prune origin会在 7 天后自动清理 - 用错会导致：本该走审批的发布被跳过，或本该保留的集成分支被定时脚本删掉
真正容易被忽略的点是：远程分支名一旦推送，就成为团队其他成员和所有自动化系统的“事实来源”。改名要 git push origin :old-name new-name 删除再推，但已触发的流水线、PR、Jira 关联都不会自动更新——得人工补救。所以建分支前多敲一次 git status 确认本地分支名，比事后修一百个地方更省事。
