Angular项目提交信息规范详解
angular Deliver web apps with confidence 🚀 
项目地址: https://gitcode.com/gh_mirrors/angular26/angular
前言
在大型前端项目中，良好的提交信息规范是项目维护的重要基础。Angular项目采用了一套严格的提交信息格式规范，这套规范不仅提高了代码审查效率，还能自动生成变更日志，为开发者提供了清晰的版本演进历史。
提交信息的基本结构
Angular项目的提交信息由三个部分组成：
- Header（头部）：必填项，包含类型、范围和简短描述
- Body（正文）：除文档类提交外必须填写，至少20个字符
- Footer（脚注）：可选，用于说明破坏性变更和弃用情况
格式示例：
<type>(<scope>): <short summary>
<空行>
<body>
<空行>
<footer>
提交头部详解
提交类型（Type）
提交类型是必填项，必须是以下类型之一：
| 类型 | 说明 | |------------|------------------------------------------| | build | 构建系统或外部依赖变更 | | ci | CI配置文件和脚本变更 | | docs | 仅文档变更 | | feat | 新增功能 | | fix | 修复bug | | perf | 性能优化变更 | | refactor | 既不修复bug也不添加功能的代码重构 | | test | 添加或修正测试 |
提交范围（Scope）
范围字段是可选的，表示变更影响的npm包或功能模块。Angular项目定义了以下标准范围：
- 核心模块：
core、compiler、compiler-cli等 - 平台相关：
platform-browser、platform-server等 - 工具链：
bazel、dev-infra等 - 文档：
docs-infra、changelog等
特殊范围说明：
packaging：影响所有npm包的布局变更migrations：ng update迁移相关变更- 空范围：适用于跨多个包的变更或通用文档修改
摘要（Summary）
摘要部分编写规范：
- 使用祈使语气和现在时态（如"change"而非"changed"）
- 首字母不大写
- 结尾不加句号
提交正文规范
正文部分需要详细说明变更动机和影响：
- 同样使用祈使语气和现在时态
- 解释"为什么"要进行这个变更
- 可对比新旧行为以说明变更影响
提交脚注说明
脚注部分用于特殊说明：
破坏性变更（Breaking Change）
格式要求：
BREAKING CHANGE: <简短摘要>
<空行>
<详细描述+迁移指南>
弃用声明（Deprecation）
格式要求：
DEPRECATED: <被弃用内容>
<空行>
<详细描述+推荐替代方案>
回滚提交规范
回滚某次提交时：
- 头部以
revert:开头 - 正文包含被回滚提交的SHA和回滚原因
示例：
revert: fix(core): memory leak in component factory
This reverts commit 1234567890abcdef,
由于修复方案导致其他组件渲染异常，需要重新设计解决方案
实践建议
- 类型选择：准确选择类型有助于自动化工具分类处理
- 范围界定：明确范围可以帮助团队成员快速定位变更影响
- 摘要编写：保持简洁但信息完整，便于快速浏览历史
- 正文详实：详细说明变更背景，减少后续维护成本
- 破坏性变更：务必提供清晰的迁移指南
这套规范虽然严格，但能显著提升大型项目的可维护性。对于Angular这样的框架项目，良好的提交历史就像项目的"编年史"，帮助开发者理解每个变更背后的决策过程。
angular Deliver web apps with confidence 🚀 项目地址: https://gitcode.com/gh_mirrors/angular26/angular
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
扫一扫
952
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
