分支管理规范

---

一、分支模型

分支	用途	来源	保护规则	生命周期
main	主干，随时可发布	—	禁直推；≥　　人评审 + CI 全绿方可合入	永久
feature/	功能开发	main	个人分支，合入前 rebase 主干	≤　　天
fix/	缺陷修复	main	同 feature	≤　　天
hotfix/	线上紧急修复	release tag	可加急单人评审，事后补记录	≤　　天
release/x.y	版本预发与验收	main	只接受修复类合入	版本发布后删除

二、命名约定

feature/　　-　　-需求简述     # 需求号开头，如 feature/1234-order-export
fix/BUG-　　-　　              # 缺陷修复，关联缺陷单
hotfix/v　　.　　-　　          # 线上紧急修复，带目标版本
chore/　　-　　                 # 构建 / 依赖 / 文档等杂项

规则：全小写，单词间用中划线；禁用个人姓名、日期、"tmp"、"new" 等无信息量命名；分支名须能反推关联工单。

三、提交信息规范

格式：<type>(<scope>): <subject>，正文说明动机与影响范围。

type	含义	示例
feat	新功能	feat(order): 支持批量导出订单
fix	缺陷修复	fix(auth): 修复 Token 过期未刷新
refactor	重构（不改行为）	refactor(repo): 抽离查询构造器
test / docs / chore	测试 / 文档 / 杂项	docs(readme): 补充本地启动说明

四、合并规则

• 合并前 rebase 最新 main，解决冲突后 CI 重跑全绿
• feature 合入统一 Squash，保持主干历史线性整洁
• hotfix 合入 release 后须反向 cherry-pick 回 main，防修复丢失
• 超过 　　 天未活动的分支定期清理，清理前群内公示
• 禁止 force push 共享分支（main / release 一律禁）

五、发布流程

1. 从 main 拉出 release/x.y，冻结新需求合入；
2. 预发环境验收，回归 P0 用例并完成性能 / 安全专项；
3. 打 tag vx.y.z 触发发布流水线，按《发布检查清单》执行；
4. 发布成功后删除 release 分支，tag 作为唯一可追溯快照保留。

本规范与《编码规范》配套执行；争议场景由 　　　　仲裁。