规范的核心目标：降低协作成本、提高代码可追溯性、版本管理。
一、分支规范
| 分支类型 | 分支名称格式 | 作用说明 | 生命周期 | 合并目标 |
|---|---|---|---|---|
| 主分支 | main（或 master） | 存放主要代码，禁止直接提交代码 | 永久 | 仅接收 dev 合并 |
| 开发者分支 | dev/xxx | 开发分支，xxx为开发者名称 | 永久 | 合并到 main |
二、提交日志规范
提交日志格式统一为：类型(范围可选): 描述信息，核心是「结构化、一眼看懂提交目的」。
1. 基本格式
bash
<type>(<scope>): <description>2. 核心类型（type）
| 类型 | 适用场景 | 示例 |
|---|---|---|
feat | 新增功能（如新增接口、页面、功能模块） | feat(user): 新增用户注册接口 |
fix | 修复bug（生产/开发环境的功能异常） | fix(order): 修复订单支付状态同步问题 |
docs | 仅修改文档（如README、注释、接口文档），不涉及代码逻辑 | docs: 更新API文档参数说明 |
style | 代码格式调整（如缩进、空格、命名规范），不改变代码逻辑 | style: 统一变量命名为小驼峰 |
refactor | 代码重构（既不新增功能，也不修复bug，如优化逻辑、提取公共方法） | refactor(utils): 提取日期格式化工具 |
perf | 性能优化（如减少接口耗时、降低内存占用） | perf: 优化列表查询SQL，耗时从500ms→50ms |
test | 新增/修改测试代码（如单元测试、集成测试） | test(user): 补充用户登录单元测试 |
chore | 构建/工具类操作（如依赖更新、配置修改、脚本调整） | chore: 更新npm依赖到最新版本 |
3. 范围（scope）可选
用于指定提交影响的模块，如 user（用户模块）、order（订单模块）、payment（支付模块）、config（配置）等，无明确模块可省略。
4. 描述信息（description）要求
- 首字母小写，结尾不加句号；
- 简洁明了（10字以内最佳），直接说明「做了什么」；
- 避免模糊表述（如「修改了一些问题」「优化代码」）。
5. 完整示例
bash
# 有范围+详细说明
feat(order): 新增订单批量导出功能
# 无范围+简单描述
fix: 修复移动端适配错位问题
# 重构+性能优化
refactor(utils): 重构字符串处理工具，提升执行效率三、配套工具（可选）
- 提交规范校验：使用
commitlint+husky，强制提交日志符合格式，避免不规范提交； - 自动生成日志：使用
standard-version或release-it，根据提交日志自动生成 CHANGELOG.md，无需手动编写； - 分支保护：在GitLab/GitHub中设置
main/develop分支保护，禁止直接推送、强制推送，必须通过MR/PR合并。
Git 分支日志提交规范https://wmhwiki.cn/posts/2025/git-standards