创建新分支需严格遵循团队规范：必须匹配CI/CD规则、权限系统和PR模板逻辑，错用前缀或漏Jira编号会导致CI跳过构建、PR被拒、Jira状态不更新；git checkout -b feature/x推不上去主因是本地无origin/main远程跟踪信息，须先git fetch origin再创建分支，推荐git switch -c feature/x --track origin/main，并首次推送时加-u参数。
直接说结论：创建新分支不是“随便起个名 push 就完事”，它必须匹配团队 CI/CD 规则、权限系统和 PR 模板逻辑；错用前缀或漏 Jira 编号，CI 流水线可能跳过构建、PR 被自动拒绝、Jira 状态不更新。
git checkout -b feature/x 为什么推不上去？
常见报错：fatal: Not a valid object name: 'origin/main' 或 non-fast-forward 拒绝推送。
- 根本原因：你本地没有
origin/main的远程跟踪信息，git checkout -b feature/x origin/main会失败——origin/main是远程引用，不是本地分支 - 正确流程必须分两步：
git fetch origin（同步远程元数据）→git checkout -b feature/order-create-JIRA-1234 origin/main - Git 2.23+ 更推荐：
git switch -c feature/order-create-JIRA-1234 --track origin/main，语义更明确，且自动建立上游追踪 - 如果已存在同名远程分支（比如别人建过
feature/order-create-JIRA-1234），直接git push会被拒绝；首次推送必须加-u：git push -u origin feature/order-create-JIRA-1234
feature/、bugfix/、hotfix/ 前缀到底影响什么？
这不是命名洁癖，是自动化流水线的触发开关。
-
feature/xxx→ CI 默认只部署到 dev 环境，跑全量单元测试 + 静态扫描，PR 模板自动带「需求链接」「UI 截图占位」字段 -
bugfix/xxx→ 流水线跳过 e2e 测试，但强制运行回归测试集；合并目标被限制为develop，不能直推main -
hotfix/xxx→ 自动跳过部分集成测试，构建产物直推预发环境；合并后系统会强制向main和develop双向同步 -
fix/、dev/、test/这类前缀不会被 Jenkins/GitLab CI 的 branch filter 匹配，等于“隐身分支”，CI 不执行、权限不生效、PR 模板为空白
Jira 编号为什么必须前置且唯一？
分支名里的编号不是给人看的，是给正则脚本和审计系统吃的。
- CI 构建时会用
feature/(PROJ-\d+)-.*提取编号，漏写或放末尾（如feature/login-PROJ-123）会导致提取失败 - Jira 插件靠这个编号自动标记 ticket 状态；编号缺失 → PR 合并后 ticket 卡在 “In Progress”，没人知道它已上线
- 多个 ticket 关联时拼接（如
feature/PROJ-123-and-456）会破坏正则，系统只认第一个完整匹配项；应选主导需求编号，其余在 commit message 或 PR description 补充 - 大小写敏感：
PROJ-123✅，proj-123❌（Jira 实例配置决定）
release/v1.2.0 和 release/login-ui 本质不同
前者是发布窗口，后者是临时集成分支——混用会导致上线审批流卡死或 tag 打错。
-
release/v1.2.0：语义化版本号，用于冻结代码、打v1.2.0tag、走正式上线审批；该分支生命周期长，测试通过后必须合入main和develop -
release/login-ui：业务描述型，仅用于短周期联调（ - 误把
release/login-ui当成正式发布分支，可能导致：tag 名错误（打成login-ui）、上线包缺失 changelog、审计无法追溯版本来源
最常被忽略的一点：分支创建后，没人检查它是否真的基于 origin/main 的最新提交。用 git merge-base main feature/x 对比 SHA1，比肉眼看 git log --oneline -n5 更可靠。
