Angular提交信息规范

良好的Git提交信息对于项目维护和团队协作至关重要。在Angular项目中，采用规范化的提交信息可以帮助团队成员更好地理解代码变更的目的和影响范围。下面我将详细介绍Angular项目中的提交信息规范。

为什么需要提交信息规范？

规范的提交信息有以下好处：

  1. 提高代码审查效率

  2. 自动生成更新日志

  3. 快速筛选和查找特定类型的变更

  4. 便于团队成员理解变更内容和目的

  5. 帮助新成员快速了解项目历史

Angular提交信息格式

Angular遵循"约定式提交"(Conventional Commits)规范，基本格式如下：

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]

提交类型

常用的提交类型包括：

  • feat: 新功能

  • fix: 修复bug

  • docs: 文档更新

  • style: 代码风格修改(不影响代码功能)

  • refactor: 代码重构(既不是新增功能，也不是修复bug)

  • perf: 性能优化

  • test: 添加或修改测试代码

  • build: 构建系统或外部依赖项修改

  • ci: CI配置文件和脚本修改

  • chore: 其他不修改src或测试文件的更改

作用域

作用域用于说明提交影响的范围，例如：

feat(auth): 添加用户登录功能
fix(router): 修复路由跳转bug

作用域应该是项目中的模块名、组件名或功能区域。

描述

描述部分应简洁明了地说明本次提交的内容，遵循以下规则：

  • 使用动词开头，使用第一人称现在时

  • 首字母不要大写

  • 结尾不加句号

正文

正文是对本次提交的详细描述，应该解释清楚：

  • 为什么进行这次更改

  • 具体做了哪些更改

  • 这些更改会带来什么影响

脚注

脚注通常用于说明重大变更(BREAKING CHANGE)或关闭的issue：

BREAKING CHANGE: 认证API发生变更，客户端需要更新调用方式

Closes #123, #456

实际示例

1. feat: 新功能

feat(auth): 实现基于JWT的认证机制 添加了用户登录和注册功能，使用JWT进行身份验证。 

新增了AuthService服务，处理token的存储和验证逻辑。 

Closes #45

2. fix: 修复bug

fix(data): 修复数据加载失败问题 

解决了在网络不稳定情况下数据加载失败的问题， 添加了重试机制和友好的错误提示。 

Fixes #78

3. docs: 文档更新

docs(readme): 更新项目安装和配置说明 

完善了README文件中的安装步骤和环境配置说明， 添加了常见问题的解决方案和注意事项。

4. style: 代码风格修改

style(component): 统一组件样式命名规范 

调整了所有组件中的CSS类名，使用BEM命名规范， 不影响任何功能实现和样式效果。

5. refactor: 代码重构

refactor(ext): 将utils中的扩展工具移至独立的ext包 


将原本位于utils中的扩展工具方法移动到专门的ext包下， 提高了代码组织结构的清晰度和模块化程度。 此变更不影响现有功能，仅调整了代码结构。

6. perf: 性能优化

perf(rendering): 优化列表渲染性能 

实现了虚拟滚动功能，减少了DOM节点数量， 大幅提升了大数据量下的列表渲染性能和滚动流畅度。 

改进前：渲染1000条数据需要2秒 
改进后：渲染1000条数据仅需200ms

7. test: 测试相关

test(api): 添加用户API的单元测试 

为UserService中的所有方法添加了单元测试， 包括正常场景和异常场景的测试用例， 提高了代码的可靠性和稳定性。

8. build: 构建系统

build(deps): 升级Angular核心库至最新版本 

将Angular核心库从v13升级到v14， 同时更新了相关依赖，解决了潜在的安全风险。 

BREAKING CHANGE: 需要Node.js 14.0或更高版本

9. ci: CI配置修改

ci(pipeline): 优化持续集成流程 

调整了Jenkins流水线配置，实现了并行测试和构建， 将CI执行时间从15分钟减少到8分钟。

10. chore: 其他更改

chore(deps): 更新开发依赖项版本 

更新了eslint、prettier等开发工具的版本， 保持与团队最新工具链一致。

特殊场景示例

代码移动或重命名

refactor(structure): 重构项目文件结构 


将所有服务类从services目录移动到对应的功能模块目录下， 使项目结构更符合领域驱动设计的原则。 

BREAKING CHANGE: 服务导入路径发生变化，需更新引用位置

多模块修改

fix(core,shared): 修复全局状态管理问题 解决了在多标签页环境下状态同步的问题， 同时修复了shared模块中的事件广播机制。 

Fixes #123, #124

重大变更

feat(api): 重新设计RESTful API接口 

简化了API路径结构，统一了请求和响应格式， 添加了API版本控制机制。 

BREAKING CHANGE: 所有API路径和参数格式已变更， 客户端需要相应更新。详见API文档v2.0。

团队实施建议

  1. 在项目README或CONTRIBUTING文档中说明提交规范

  2. 配置提交信息模板

  3. 使用Git钩子强制检查提交信息

  4. 定期审查提交历史并给予反馈

  5. 为团队新成员提供指导和培训

通过遵循这些规范，可以使项目的Git历史更加清晰，提高团队协作效率，并为后续的项目维护提供便利。