git的提交规范

git的提交规范包括两个字段：type（必需）和subject（必需）

type用于说明 commit 的类别，只允许使用下面9个标识。

feat: 新功能（feature）

fix: 修补bug

docs: 文档（documentation）

style: 格式（不影响代码运行的变动）

refactor: 重构（即不是新增功能，也不是修改bug的代码变动）

chore: 构建过程或辅助工具的变动

revert: 撤销，版本回退

perf: 性能优化

test：测试

improvement: 改进

build: 打包

ci: 持续集成

subject是 commit 目的的简短描述，不超过50个字符。

example:

    feat(example): 订单详情增加导出功能

    -订单详情新增导出功能

 feat() 括号内的内容通常用来指明该功能更改的影响范围或上下文

作用域的选择

选择合适的作用域取决于你的项目结构和团队约定。以下是几个例子：

• 按模块或功能区划分：如果你的项目由多个独立的功能模块组成，那么可以在括号内填写模块名。

  • 示例：feat(user-auth): 添加两步验证支持

• 按前端框架组件划分：对于使用如 React, Vue 等前端框架的项目，可能会按照组件来组织。

  • 示例：feat(Header): 增加导航栏的新按钮

• 按后端服务或API端点划分：如果是在服务端工作，可能根据API端点或服务命名。

  • 示例：feat(api/v2/users): 支持批量用户创建

• 按文件夹或目录划分：有时也直接使用文件夹名称作为作用域。

  • 示例：feat(src/components): 更新组件样式

• 按技术或库划分：当更改特别针对某个库或技术时，也可以用它作为作用域。

  • 示例：feat(express): 升级到Express 5.0

• 其他自定义作用域：根据项目的具体需求，还可以使用其他任何有助于描述更改范围的标识符。

注意事项

• 遵循团队规范：确保你遵循所在团队或项目已有的提交信息格式和约定。
• 保持一致性：一旦确定了作用域的规则，尽量在整个项目中保持一致。
• 简洁明了：作用域应该简短且具有描述性，避免过长或过于模糊。

括号中的内容是为了提供额外的上下文，帮助更好地理解和分类提交。因此，选择能够清晰表达更改影响范围的词汇是非常重要的。