适用于公司内部所有研发人员，作为代码提交、代码评审、版本管理的统一规范。
1. 规范目标
- 提高代码提交可读性与可追溯性
- 统一团队提交风格，降低沟通成本
- 方便 Code Review、问题回溯、版本发布
- 为 CI/CD、自动化工具提供标准化输入
2. Git 分支管理规范
2.1 分支类型说明
| 分支 | 说明 |
|---|---|
| main / master | 稳定生产分支，禁止直接提交 |
| develop | 日常集成分支 |
| feature/* | 功能开发分支 |
| fix/* | 缺陷修复分支 |
| hotfix/* | 紧急线上修复分支 |
2.2 分支命名规范
feature/clue-auto-assign
fix/login-token-expire
hotfix/order-price-error
命名要求：
- 小写字母
- 单词使用
-分隔 - 简要体现修改内容
3. Commit Message 规范（强制）
3.1 提交格式
<type>(<scope>): <subject><body><footer>
4. Type 类型说明（必填）
| Type | 含义 |
|---|---|
| feat | 新功能 |
| fix | Bug 修复 |
| docs | 文档更新 |
| style | 代码格式调整（不影响逻辑） |
| refactor | 重构代码 |
| perf | 性能优化 |
| test | 测试相关 |
| chore | 杂项（脚本、配置、依赖） |
| build | 构建相关 |
| ci | CI/CD 配置 |
| revert | 回滚提交 |
禁止使用：update / modify / change
5. Scope 规范（推荐）
Scope 用于描述影响范围或模块。
示例：
feat(clue): 新增线索自动分配规则
fix(auth): 修复登录 token 失效问题
常用 Scope：
- user / auth / login
- clue / customer / follow
- order / pay / report
- controller / service / dao
- api / config / docker / k8s
6. Subject（标题行）规范
- 使用动词开头（现在时）
- 不超过 50 个字符
- 不加句号
- 表达清晰、简洁
正确示例
fix(user): 修复用户状态未更新问题
feat(report): 新增销售排行榜接口
错误示例
修改了一些问题
update code
临时提交
7. Body（正文）规范（推荐）
用于补充说明：
- 修改背景 / 原因
- 具体改动内容
- 核心实现思路
示例：
修复线索重复分配问题原因：
- 并发场景下分配锁失效解决方案：
- 引入数据库悲观锁
- 增加唯一索引保证幂等
8. Footer 规范（可选）
用于：
- 关联需求 / 缺陷
- 关闭 Issue
- 标记破坏性变更
示例：
Closes #123
Fixes BUG-1024
破坏性变更（必须）
BREAKING CHANGE: 接口返回结构发生变更
9. 提交粒度规范（强制）
原则
- 一次提交只做一件事
- 不混合功能与修复
- 不跨多个无关模块
正确示例
feat(clue): 新增线索导入功能
fix(clue): 修复导入失败问题
错误示例
feat: 新增功能 + 修复 bug + 改样式
10. Code Review 规范
- 必须通过 Review 才能合并
- Reviewer 至少 1 人
- 不允许提交以下内容：
- 注释掉的代码
- debug 日志
- 本地测试代码
11. 合并规范
- 使用 Merge Request / Pull Request
- 提交信息必须符合规范
- 合并前需：
- 代码可编译
- 单元测试通过
12. 工具与自动化（推荐）
- commitlint：校验 commit message
- husky：Git hooks 管理
- conventional commits：提交规范标准
建议在项目中强制启用，避免不规范提交进入主分支。
13. 常用提交示例合集
feat(crm): 新增线索自动分配规则
fix(auth): 修复 token 过期未刷新问题
docs(api): 补充线索接口说明
refactor(order): 重构订单金额计算逻辑
chore(deps): 升级 Spring Boot 版本
14. 附则
- 本规范自发布之日起执行
- 新成员入职需学习并遵守
- 如有争议，以本规范为准
维护人：研发团队
最后更新：YYYY-MM-DD