PR 标题规范是什么
在 squash 合并为主的仓库里，PR/MR 标题会成为主干上的最终提交标题（GitHub squash 默认取 PR 标题）。因此标题要按提交规范写（如 type(scope): 描述），并在 CI 里加一条对标题的格式校验，防止漏网；即便走 merge 流程，标题也是在通知、变更列表、changelog 里最先被看到的一行文字，检索价值同样重要。
基本信息
| 推荐格式 | <type>(<scope>): <描述>，与提交信息规范一致 |
|---|---|
| 校验 | 流水线里对 PR/MR 标题跑 commitlint 之类规则 |
| 编辑 | gh pr edit --title；GitLab 网页端可直接改 |
| 长度 | 保持单行且控制在合理上限内（如 100 字符） |
| 语言 | 全仓统一中文或英文，避免检索与分组困难 |
典型使用场景
- squash 合并的仓库：标题直接进主干日志，必须合格。
- changelog 自动化：工具按 type/scope 归类生成发布说明。
- 历史检索：用 fix(login) 之类前缀快速过滤相关提交。
- 多团队协作：统一格式后，非本模块的人也能看懂变更性质。
- 上游同步：维护 fork 时标题规范向被同步的上游仓库看齐。
常用示例
常用示例
gh pr create --title 'fix(login): 修复重定向循环' --body-file .github/pull_request_template.md
gh pr edit 128 --title 'fix(login): 修复重定向循环（含回归测试）'
gh pr view 128 --json title -q .title # 复核当前标题
# 流水线里对 PR 标题跑 commitlint 类校验，格式不通过则卡住合并type 前缀对照
| 前缀 | 含义 | 例子 |
|---|---|---|
| feat | 新功能 | feat(cart): 支持优惠券 |
| fix | 缺陷修复 | fix(login): 修复重定向循环 |
| docs | 文档变更 | docs(api): 补充分页说明 |
| refactor | 重构且不改行为 | refactor(db): 收拢连接池管理 |
| perf | 性能优化 | perf(list): 减少重复渲染 |
| build/style | 构建与代码风格 | build: 升级构建工具链 |
| test/chore/ci | 测试、杂务、流水线 | ci: 增加 PR 标题校验 |
标题写清变更性质与影响面，细节放正文；破坏性变更可在标题加感叹号或在正文写明 BREAKING CHANGE，便于工具识别。