Git 提交日志规范

2019-09-29  本文已影响0人  Yangwenliu

1. 为什么需要规范的提交信息?

在团队协作中，使用 Git、SVN 等这些版本管理工具。当我们提交代码的时候，往往需要编写提交信息（commit message）。

而提交信息的主要用途是：告诉这个项目的人，这次代码提交里做了些什么。一般来说，建议小步提交，即按自己的任务步骤来的提交，每一小步都有对应的提交信息。这样做的主要目的是：防止一次修改中，修改过多的文件，导致后期修改、维护、撤销等等困难。

2. 参考Angular开源项目写法

与我们日常工作稍有不同的是：工作中的 Release 计划一般都是事先安排好的，不需要一些 CHANGELOG 什么的。而开源项目需要有对应的 CHANGELOG.md ，则添加了什么功能、修改了什么等等。毕竟有很多东西是由社区来维护的。

Angular 团队建议采用以下的形式：

<type>(<scope>): <subject> // 提交消息头Message header   
<BLANK LINE> //空行
<body> // 提交具体内容
<BLANK LINE>//空行
<footer> // 额外内容

其中Header是必须的, body,footer是可选的
例子在最后

2.1 提交消息头(commit message header)

<type> , 用于以下类型说明提交类型：

  • build: 影响构建系统或外部依赖关系的更改（示例范围：gulp，-
  • broccoli，npm）
  • ci: 更改我们的持续集成文件和脚本（e.g.: Travis，GitLab等）
  • docs: 仅文档更改
  • feat: 一个新功能
  • fix: 修复错误
  • perf: 改进性能的代码更改
  • refactor: 代码更改，既不修复错误也不添加功能
  • style: 不影响代码含义的变化（空白，格式化，缺少分号等）
  • test: 添加缺失测试或更正现有测试
  • chore: 构建过程或辅助工具的变动
  • release: 版本发布
  • revert: 特殊情况，当前 commit 用于撤销以前的 commit

<scope>, 说明 commit 影响的范围

  • 最好是指定提交更改位置(结构的), 例如$location, $browser, $compile, $rootScope, ngHref, ngClick, ngView等等
  • 没有合适的范围可以使用*

<subject>, 此次提交的简短描述,不应超过50个字符

  • 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
  • 第一个字母小写
  • 结尾不加句号（.）
 // test类型实例 没有指定scope
test: fix ts api guardian and public guard tests on windows (#30105)
2.2 提交消息具体内容(commit message body)

<body> ,可选的, 此次提交详细描述,如果需要用到body,则应注意以下两点

  • 以动词开头，使用第一人称现在时，比如change，而不是changed或changes
  • 应该说明代码变动的动机，以及与以前行为的对比。
// body实例
More detailed explanatory text, if necessary.  Wrap it to 
about 72 characters or so. 

Further paragraphs come after blank lines.

- Bullet points are okay, too
- Use a hanging indent
2.3 提交消息尾述(commit message footer)

<footer> ,可选的, 此次提交描述的补充, 通常有两种情况

  • 不兼容的变动, 如果当前代码与上一个版本不兼容，则 Footer 部分以BREAKING CHANGE:开头，后面是对变动的描述、以及变动理由和迁移方法。
BREAKING CHANGE: isolate scope bindings definition has >changed and
   the inject option for the directive controller injection was >removed.
   
   To migrate the code follow the example below:
  
  Before:
   
   scope: {
     myAttr: 'attribute',
     myBind: 'bind',
     myExpression: 'expression',
     myEval: 'evaluate',
     myAccessor: 'accessor'
   }
   
   After:
   
   scope: {
    myAttr: '@',
    myBind: '@',
    myExpression: '&',
    // myEval - usually not useful, but in cases where the >expression is assignable, you can use '='
     myAccessor: '=' // in directive's template change >myAccessor() to myAccessor

  }
  • 关闭 Issue, 需要关闭一个或多个某个issue
Closes #123, #456, #789

3. Git获取提交消息格式化输出

//1. 获取提交列表message header 
 git log <last tag> HEAD --pretty=format:%s
// 2. 过滤 类型 type
 git log <last release> HEAD --grep feature
// 3. 跳过一些无关紧要的提交
 git bisect skip $(git rev-list --grep irrelevant <good place> HEAD)

4. 与此同时还有一个名为 Conventional Commits 的规范，建议采用相似的形式。

5. 下面是一些提交例子

5.1 revert && refactor

revert: refactor(ivy): remove styling state storage and introduce dir…

…ect style writing (#32259)

This reverts commit 15aeab1.

5.2 docs && footer

docs: move renderer2 deprecation guide into own file (#32626)

PR Close #32626

5.3 release

release: cut the v9.0.0-next.6 release

5.4 ci

ci: pin docker images by ID for hermeticity (#32602)

Previously, the docker images used on CI where specified by a tag
(`10.16` and `10.16-browsers`). Since tags are not immutable, this only
pins specific characteristics of the environment (e.g. the OS type and
the Node.js version), but not others. Especially when using a tag that
does not specify the patch version (e.g. `10.16` instead of `10.16.0`),
it is inevitable that the image will change at some point, potentially
leading to unrelated failures due to changes in the environment.

One source of such failures can be the Chrome version used in tests.
Since we install a specific ChromeDriver version (that is only
compatible with specific Chrome version ranges), unexpectedly updating
to a newer Chrome version may break the tests if the new version falls
outside the range of supported version for our pinned ChromeDriver.

Using a tag that specifies the patch version (e.g. `10.16.0`) or even
the OS version (e.g. `10.16.0-buster`) is safer (i.e. has a lower
probability of introducing the kind of breakages described above), but
is still not fully hermetic.

This commit prevents such breakages by pinning the docker images by ID.
Image IDs are based on the image's digest (SHA256) and are thus
immutable, ensuring that all CI jobs will be running on the exact same
image.

See [here][1] for more info on pre-built CircleCI docker images and more
specifically [pinning images by ID][2].

[1]: https://circleci.com/docs/2.0/circleci-images
[2]: https://circleci.com/docs/2.0/circleci-images#using-a-docker-image-id-to-pin-an-image-to-a-fixed-version

PR Close #32602

5.5 pref

perf(ivy): check for animation synthetic props in dev mode only ([#32578](https://github.com/angular/angular/pull/32578))

5.6 fix

fix(ngcc): only back up the original `prepublishOnly` script and not …

…the overwritten one (#32427)

In order to prevent `ngcc`'d packages (e.g. libraries) from getting
accidentally published, `ngcc` overwrites the `prepublishOnly` npm
script to log a warning and exit with an error. In case we want to
restore the original script (e.g. "undo" `ngcc` processing), we keep a
backup of the original `prepublishOnly` script.

Previously, running `ngcc` a second time (e.g. for a different format)
would create a backup of the overwritten `prepublishOnly` script (if
there was originally no `prepublishOnly` script). As a result, if we
ever tried to "undo" `ngcc` processing and restore the original
`prepublishOnly` script, the error-throwing script would be restored
instead.

This commit fixes it by ensuring that we only back up a `prepublishOnly`
script, iff it is not the one we created ourselves (i.e. the
error-throwing one).

PR Close #32427

5.7 等等 具体参考anuglar开源项目

上一篇下一篇

猜你喜欢

热点阅读