乐趣区

关于git:Git-Commit-规范应该用起来

jiezi

本文是对后面系列文章的补充与欠缺。后面的介绍，利用了 husky 与 lint-staged 使得在提交之前做一些 ESLint 和 Prettier 的操作，明天来补充完 Commit Message 提交阐明标准。

Git 是目前最先进的分布式版本控制系统，Git 每次提交代码时，都须要写 Commit Message（提交阐明），否则不容许提交。

# 单行（亦可多行输出，输出一个双引号，按 Enter 键即可，最初补全一个双引号）$ git commit -m "xxx"

# 多行输出，输出命令进入编辑模式
$ git commit

在团队多人合作中，一份清晰扼要的 Commit Message 很重要，它能够让咱们分明理解本次代码提交的目标以及解决了具体什么问题。也可能让后续 Code Review、信息查找、版本回退都更加高效牢靠。

目前，社区有多种 Commit Message 的写法标准。本文介绍 Angular 标准，这是目前应用最广的写法，比拟正当和系统化，并且有配套的工具。

Commit Message 标准

每次提交，Header 是必须的，而 Body 和 Footer 能够省略。

不论哪一部分，任何一行都不得超过 72 个字符（或 100 个字符）。这是为了防止主动换行影响好看。

<Header>
< 空行 >
<Body>
< 空行 >
<Footer>
Header 局部

它包含 type、scope、subject 三局部，其中 type、subject 是必须的，而 scope 是可选的。

<type>(<scope>): <subject>
  1. type 用于阐明 commit 的类型，只容许应用上面几个标识：
  • feat 新性能

A new feature

  • fix 修复 bug

A bug fix

  • docs 仅蕴含文档的批改

Documentation only changes

  • style 格式化变动，不影响代码逻辑。比方删除多余的空白，删除分号等

Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)

  • refactor 重构，既不是新增性能，也不是批改 bug 的代码变动

A code change that neither fixes a bug nor adds a feature

  • perf 性能优化

A code change that improves performance

  • test 减少测试

Adding missing tests or correcting existing tests

  • build 构建工具或内部依赖包的批改，比方更新依赖包的版本等

Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)

  • ci 继续集成的配置文件或脚本的批改

Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)

  • chore 杂项，其余不批改源代码与测试代码的批改

Other changes that don’t modify src or test files

  • revert 撤销某次提交

Reverts a previous commit

如果 type 为 feat 和 fix，则该 commit 将必定会呈现在 Change Log 中。其余状况（docs、chore、style、refactor、test）由你决定，要不要放入 Change Log 中，倡议是不要。

  1. scope 用于阐明 commit 影响的范畴，比方数据层、管制层、视图层等。依据我的项目自身状况解决，如: views, components, utils, test…
  2. subject 是 commit 目标的简短形容，不超过 50 个字符。
  • 以动词结尾，应用第一个人称当初时，比方 change，而不是 changed 或者 changes
  • 第一字母小写
  • 结尾不加句号（.）
Body 局部

Body 局部是对本次 commit 的详细描述，能够分成多行。上面是一个范例：

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

留神两点：

  • 应用第一人称当初时，比方应用 change 而不是 changed 或者 changes。
  • 应该阐明代码变动的动机，以及与之前行为的比照。
Footer 局部

Footer 局部只用于两种状况。

  1. 不兼容的变动

如果以后代码与上一个版本不兼容，则 Footer 局部以 BREAKING CHANGE 结尾，前面是对变动的形容以及变动理由和迁徙办法。

BREAKING CHANGE: isolate scope bindings definition has changed.

    To migrate the code follow the example below:

    Before:

    scope: {myAttr: 'attribute',}

    After:

    scope: {myAttr: '@',}

    The removed `inject` wasn't generaly useful for directives so there should be no code using it.
  1. 敞开 Issue

如果以后 commit 针对某个 issue，那么旧能够在 Footer 局部敞开这个 issue。

# 敞开单个
Closes #123

# 敞开多个
Closes #123, #234, #345
Revert

还有一种非凡状况，如果以后 commit 用于撤销以前的 commit，则必须以 revert: 结尾，前面跟着被撤销 Commit 的 Header。

Body 局部格局是固定的，必须写成 This reverts commit <hash>.，其中的 hash 是被撤销 commit 的 SHA 标识符。

revert: feat(pencil): add 'graphiteWidth' option

This reverts commit 667ecc1654a317a13331b17617d973392f415f02.

如果以后 commit 与被撤销的 commit 在同一个公布（release）外面，那么它都不会呈现在 Change Log 外面。如果两者在不同的公布，那么以后 commit，会呈现在 Change Log 的 Reverts 小标题上面。

Commitizen

Commitizen 是一个撰写合乎下面 Commit Message 规范的一款工具。

能够全局装置或者我的项目本地装置，我采纳后者，但都会介绍一下。

全局装置 

# 全局装置办法

# 下载
$ yarn global add commitizen cz-conventional-changelog

# 创立 .czrc 文件
$ vi ~/.czrc

# 写入如下内容并保留
{"path": "cz-conventional-changelog"}

# 完了之后，能够应用 git cz 来代替 git commit 了。

我的项目部分装置 

$ yarn add --dev commitizen cz-conventional-changelog

接着往 package.json 增加配置：

{
  "scripts": {
    "commit": "git-cz",
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"
  },
  "config": {
    "commitizen": {"path": "./node_modules/cz-conventional-changelog"}
  }
}

commitizen 与 cz-conventional-changelog 的关系？

commitizen 依据不同的 Adapter 配置 Commit Message。比方，要应用 Angular 的 Commit Message 格局，能够装置 cz-conventional-changelog。还有很多其余的 Adapter…

实际

其中 scope、breaking changes、issue 等非必须项可回车跳过。

生成 Change Log

如果你的所有 Commit 都合乎 Angular 格局，那么公布新版本时，Change Log 就能够用脚本主动生成。

生成的文档包含以下三个局部。

  • New features
  • Bug fixes
  • Breaking changes.

conventional-changelog 就是生成 Change Log 的工具，此前已装置并配置 

{
  "scripts": {"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s -r 0 && git add CHANGELOG.md"}
}

运行以下命令生成 CHANGELOG 文件，其中 feat 和 fix 类型的变动会生成在外面。

$ yarn run changelog

每个局部都会列举相干的 commit，并且有指向这些 commit 的链接。当然，生成的文档容许手动批改，所以公布前，你还能够增加其余内容。

文章的示例 Demo 在这里 ???? GitHub: wechat_applet_demo，欢送 Star ????。

参考

  • Commit message 和 Change log 编写指南（阮一峰老师）
  • 应用 commitizen 标准 Git 提交阐明
退出移动版