Angular git commit message提交规范

原创
07/07 15:26
阅读数 273

Angular git commit message提交规范

更新时间:2020年07月07日 15:29:03

原文链接

原文链接

Commit Message Guidelines(提交 Message 准则)

We have very precise rules over how our git commit messages can be formatted. This leads to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate the Angular change log.

关于如何格式化git commit message,我们有非常严格的规范。这会使提交的message更具有可读性,并且在查看项目历史记录时更易于追溯。同时,我们使用git commit message生成Angular更新日志。

Commit Message Format(提交Message格式)

Each commit message consists of a header, a body and a footer. The header has a special format that includes a type, a scope and a subject:

每个提交的message均由header,body和footer组成。header具有特殊的格式,其中包括type(类型),scope(范围)和subject(主题):

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>

The header is mandatory and the scope of the header is optional.

header是必需的,header的scope是选填的。

Any line of the commit message cannot be longer than 100 characters! This allows the message to be easier to read on GitHub as well as in various git tools.

提交message的任何一行都不能超过100个字符!这种限制使得该message在GitHub以及各种git工具中更易于阅读。

The footer should contain a closing reference to an issue if any.

页脚应包含对问题的结尾引用(如果有)。

Samples: (even more samples)

例子:(甚至更多例子

docs(changelog): update changelog to beta.5
fix(release): need to depend on the latest rxjs and zone.js

The version in our package.json gets copied to the one we publish, and users need the latest of these.

Revert(回退)

If the commit reverts a previous commit, it should begin with revert: , followed by the header of the reverted commit. In the body, it should say: This reverts commit <hash>., where the hash is the SHA of the commit being reverted.

如果本次提交还原了先前的提交,则应以revert:开头,后跟还原的提交的标头。在body中,应该标明:这将还原提交<hash>。其中hash是要还原的提交的SHA。

Type(类型)

Must be one of the following:

必须为以下之一:

  • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
  • build: 影响构建系统或外部依赖项的更改(示例范围:gulp,broccoli,npm)
  • ci: Changes to our CI configuration files and scripts (example scopes: Circle, BrowserStack, SauceLabs)
  • ci: 对我们的CI配置文件和脚本的更改(示例范围:Circle,BrowserStack,SauceLabs)
  • docs: Documentation only changes
  • docs: 仅文档更改
  • feat: A new feature
  • feat: 一项新的功能
  • fix: A bug fix
  • fix: 一个bug的修复
  • perf: A code change that improves performance
  • perf: 代码优化,提高性能
  • refactor: A code change that neither fixes a bug nor adds a feature
  • refactor: 既不修复bug也不增加新功能的代码更改
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • style: 不会影响代码含义的更改(空格,格式,缺少分号等)
  • test: Adding missing tests or correcting existing tests
  • test: 添加缺失的测试或更正现有的测试

Scope(范围)

The scope should be the name of the npm package affected (as perceived by the person reading the changelog generated from commit messages).

作用域应该是受影响的npm软件包的名称(由读取从提交消息生成的变更日志的人所感知)。

The following is the list of supported scopes:

以下是受支持范围的列表:

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

There are currently a few exceptions to the "use package name" rule:

当前,“使用包名称”规则有一些例外:

  • packaging: used for changes that change the npm package layout in all of our packages, e.g. public path changes, package.json changes done to all packages, d.ts file/format changes, changes to bundles, etc.
  • packaging: 用于更改所有包中npm包布局的更改,例如公用路径更改,对所有软件包进行的package.json更改,d.ts文件/格式更改,对包的更改等。
  • changelog: used for updating the release notes in CHANGELOG.md
  • changelog: 用于更新CHANGELOG.md中的发行说明
  • docs-infra: used for docs-app (angular.io) related changes within the /aio directory of the repo
  • docs-infra:用于仓库的/ aio目录中与docs-app(angular.io)相关的更改
  • dev-infra: used for dev-infra related changes within the directories /scripts, /tools and /dev-infra
  • dev-infra: 用于/ scripts,/ tools和/ dev-infra目录中与dev-infra相关的更改
  • migrations: used for changes to the ng update migrations.
  • migrations: 用于更改ng更新迁移。
  • ngcc: used for changes to the Angular Compatibility Compiler
  • ngcc: 用于更改Angular Compatibility Compiler
  • ve: used for changes specific to ViewEngine (legacy compiler/renderer).
  • ve: 用于特定于ViewEngine的更改(旧版编译器/渲染器)。
  • none/empty string: useful for style, test and refactor changes that are done across all packages (e.g. style: add missing semicolons) and for docs changes that are not related to a specific package (e.g. docs: fix typo in tutorial).
  • none / empty string: 适用于在所有软件包中进行的样式,测试和重构更改(例如style:添加缺少的分号)以及与特定软件包无关的docs更改(例如docs:教程中的拼写错误)。

Subject(主题)

The subject contains a succinct description of the change: use the imperative, present tense: "change" not "changed" nor "changes" don't capitalize the first letter no dot (.) at the end

主题包含对更改的简洁描述:使用命令式现在时态:“change”既不是“changed”也不是“changes”,不要大写首字母,最后不要加点号(。)。

Body(内容)

Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

就像在主题中一样,使用命令式现在时态:“change”而不是“changed”或“changes”。内容应包括改变的目的,并将其与以前的行为进行对比。

Footer(页脚)

The footer should contain any information about Breaking Changes and is also the place to reference GitHub issues that this commit Closes.Breaking Changes should start with the word BREAKING CHANGE: with a space or two newlines. The rest of the commit message is then used for this.

页脚应包含有关Breaking Changes的所有信息,也是引用此提交关闭的GitHub问题的地方。重大更改应以单词BREAKING CHANGE开头:用空格或两个换行符。然后,将其余的提交消息用于此目的。

A detailed explanation can be found in this document.

可以在本文档中找到详细说明。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部