首页 设计开发 规范

# git 提交规范

  • 参考规范 Angular 的提交约定。
    • feat 增加新功能
    • fix 修复问题 / BUG
    • style 代码风格相关无影响运行结果的
    • perf 优化 / 性能提升
    • refactor 重构
    • revert 撤销修改
    • test 测试相关
    • docs 文档 / 注释
    • chore 依赖更新 / 脚手架配置修改等
    • workflow 工作流改进
    • ci 持续集成
    • types 类型定义文件更改
    • wip 开发中

# 提交消息格式

每个提交消息都由一个 header、一个 body 和一个 footer 组成。

<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

header 是强制性的， header 的范围是可选的。并且必须符合 提交消息头 格式。

除了 “文档” 类型的 body 提交之外，所有提交都是强制性的。当正文出现时，它必须至少有 20 个字符长并且必须符合 提交消息正文 格式。

footer 是可选的。 提交消息页脚 格式描述了页脚的用途和它必须具有的结构。

# 提交消息头

<type>(<scope>): <short summary>
  │       │             │
  │       │             └─⫸ Summary in present tense. Not capitalized. No period at the end.
  │       │
  │       └─⫸ Commit Scope: animations|bazel|benchpress|common|compiler|compiler-cli|core|
  │                          elements|forms|http|language-service|localize|platform-browser|
  │                          platform-browser-dynamic|platform-server|router|service-worker|
  │                          upgrade|zone.js|packaging|changelog|docs-infra|migrations|ngcc|ve
  │
  └─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test

<type> 和 <summary> 字段是必需的，字段 (<scope>) 是可选的。

# Type

必须是以下之一：

  • build: 响构建系统或外部依赖项的更改（示例范围：gulp、broccoli、npm）
  • ci: 更改我们的 CI 配置文件和脚本（例如：CircleCi、SauceLabs）
  • docs: 仅文档更改
  • feat: 一个新功能
  • fix: 错误修复
  • perf: 提高性能的代码更改
  • refactor: 既不修复错误也不添加功能的代码更改
  • test: 添加缺失的测试或纠正现有的测试

# Scope

范围应该是受影响的 npm 包的名称（由阅读提交消息生成的变更日志的人所感知）。

以下是支持的范围列表：

  • animations
  • bazel
  • benchpress
  • common
  • compiler
  • compiler-cli
  • core
  • elements
  • forms
  • http
  • language-service
  • localize
  • platform-browser
  • platform-browser-dynamic
  • platform-server
  • router
  • service-worker
  • upgrade
  • zone.js

“使用包名” 规则目前有一些例外情况：

  • packaging ：用于更改我们所有包中的 npm 包布局的更改，例如公共路径更改、对所有包所做的 package.json 更改、d.ts 文件 / 格式更改、对包的更改等。
  • changelog ：用于更新 CHANGELOG.md 中的发行说明
  • dev-infra : 用于目录 /scripts 和 /tools 中与 dev-infra 相关的更改
  • docs-infra : 用于 repo 的 /aio 目录中与 docs-app (angular.io) 相关的更改
  • migrations ：用于更改 ng update 迁移。
  • ngcc ：用于更改 Angular 兼容性编译器
  • ve ：用于特定于 ViewEngine（旧版编译器 / 渲染器）的更改。
  • none/empty string：对所有包（例如）进行 test 的更改和与特定包无关的文档更改（例如）很有用。 refactor``test: add missing unit tests``docs: fix typo in tutorial

# summary

使用摘要字段提供更改的简洁描述：

  • 使用祈使语气，现在时：“change” 不是 “changed” 也不是 “changes”
  • 第一个字母不要大写
  • 末尾没有点 (.)

# 提交消息头

就像在总结中一样，使用祈使语气，现在时：“fix” 不是 “fixed” 也不是 “fixes”。

解释提交消息正文中更改的动机。此提交消息应解释您进行更改的原因。您可以将先前行为与新行为进行比较，以说明更改的影响。

# 提交消息页脚

页脚可以包含有关重大更改和弃用的信息，也是引用 issues、Jira tickets 和此提交关闭或相关的其他 PR 的地方。例如：

BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>

或者

DEPRECATED: <what is deprecated>
<BLANK LINE>
<deprecation description + recommended update path>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>

重大变更部分应以短语 BREAKING CHANGE: 开头，后跟重大变更摘要、空白行和包括迁移说明的重大变更的详细说明。

类似地，弃用部分应以 DEPRECATED: 开头，然后是弃用内容的简短描述、空行和弃用的详细描述，其中还提到了推荐的更新路径。

# 还原提交

如果提交还原了先前的提交，它应该以 开头 revert: ，后跟还原提交的标头。

提交消息正文的内容应包含：

  • 有关正在恢复的提交的 SHA 的信息，格式如下： This reverts commit <SHA> ,
  • 清楚地描述恢复提交消息的原因。

# 示例

img