引言

项目开发时，一个好的 Commit Message 至关重要：

  • 可以使自己或者其他开发人员能够清晰地知道每个 commit 的变更内容，方便快速浏览变更历史，比如可以直接略过文档类型或者格式化类型的代码变更。
  • 可以基于规范化的 Commit Message 生成 Change Log。
  • 可以依据某些类型的 Commit Message 触发构建或者发布流程，比如当 type 类型为 feat、fix 时我们才触发 CI 流程。

  • 确定语义化版本的版本号。比如 fix 类型可以映射为 PATCH 版本，feat 类型可以映射为 MINOR 版本。带有 BREAKING CHANGE 的 commit，可以映射为 MAJOR 版本。

  • 可以基于这些 Commit Message 进行过滤查找，比如只查找某个版本新增的功能：

1
git log --oneline --grep "^feat|^fix|^perf"

基本原则

  1. 明确性：每条提交信息应清晰地描述此次提交的目的和影响。
  2. 简洁性：避免冗长的提交信息，保持精炼。
  3. 一致性：遵循统一的格式和约定，使所有提交信息风格一致。
  4. 可追溯性：通过提交信息，可以轻松追踪代码变更的原因和背景。

提交信息格式

  • 类型（type）：表示提交的范畴，如 feat, fix, docs, style, refactor, perf, test, chore 等。
  • 范围（scope）：可选，表示提交影响的模块或文件。
  • 主题（subject）：简短描述此次提交的核心内容。

类型说明

  • feat：新功能（feature）
  • fix：修复 bug
  • docs：文档（documentation）
  • style：代码格式（不影响代码运行逻辑）
  • refactor：重构（既不是新增功能，也不是修复 bug）
  • perf：性能优化
  • test：增加缺失的测试
  • chore：构建过程或辅助工具的变动

类型说明

类型说明

范围说明

范围用于标识提交影响的特定部分，例如 ui, api, auth 等。如果提交影响多个范围，或者没有特定范围，可以省略此部分。

主题说明

主题应以祈使语气开始，例如“添加”，“修复”，“删除”等，并且首字母小写，不以句号结尾。

示例

  • feat(user): add login page
    添加用户登录页面。
  • fix(api): resolve 404 error
    解决 API 返回 404 错误的问题。
  • docs(readme): update installation guide
    更新安装指南。

一个遵循 Angular 规范的 commit 历史记录：

示例

额外细节

对于更复杂的更改，可以在主体下方添加更详细的描述，包括更改的动机、对比之前的解决方案、可能的副作用等。如果有必要，还可以添加一个“BREAKING CHANGE: ”标签，后跟破坏性变更的描述。

结语

为了更好地遵循 Angular 规范，建议在提交代码时养成不用 git commit -m，即不用-m 选项的习惯，而是直接用 git commit 或者 git commit -a 进入交互界面编辑 Commit Message。这样可以更好地格式化 Commit Message。