优雅的提交你的 Git Commit Message

时间 2019-11-05

标签优雅提交 git commit message 栏目 Git 繁體版

原文原文链接

题注：若是喜欢咱们的文章别忘了点击关注阿里南京技术专刊呦~ 本文转载自阿里南京技术专刊-知乎，欢迎大牛小牛投递阿里南京前端/后端开发等职位，详见阿里南京诚邀前端小伙伴加入~。css

commit message 是开发的平常操做, 写好 log 不只有助于他人 review, 还能够有效的输出 CHANGELOG, 对项目的管理实际相当重要, 可是实际工做中却经常被你们忽略. 但愿经过本文, 可以帮助你们重视和规范 commit message 的书写.前端

原由

知乎上有个问题: 如何写好 Git commit log? 颇有意思, 能看到各类提交风格: 有用 emoji 的, 有用唐诗的, 有用随机生成的. 风格没有对错, 只要可以体现出 commit 所作的修改便可.node

可是最让我印象深入的是 @李华桥的答案:git

这种东西，固然要借助工具了，才可以写得即规范，又格式化，还可以支持后续分析。目前比较建议的是，使用终端工具 commitizen/cz-cli + commitizen/cz-conventional-changelog + conventional-changelog/standard-version 一步解决提交信息和版本发布。
甚至，若是想更狠一点，在持续集成里面加入 marionebl/commitlint 检查 commit 信息是否符合规范，也不是不能够。github

本文就顺着这个方向, 给你们介绍下如何保障项目 commit message 的规范和格式化.npm

Commit Message 格式

目前规范使用较多的是 Angular 团队的规范, 继而衍生了 Conventional Commits specification. 不少工具也是基于此规范, 它的 message 格式以下:json

<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
复制代码

咱们经过 git commit 命令带出的 vim 界面填写的最终结果应该相似如上这个结构, 大体分为三个部分(使用空行分割):vim

标题行: 必填, 描述主要修改类型和内容
主题内容: 描述为何修改, 作了什么样的修改, 以及开发的思路等等
页脚注释: 放 Breaking Changes 或 Closed Issues

分别由以下部分构成:后端

type: commit 的类型
feat: 新特性
fix: 修改问题
refactor: 代码重构
docs: 文档修改
style: 代码格式修改, 注意不是 css 修改
test: 测试用例修改
chore: 其余修改, 好比构建流程, 依赖管理.
scope: commit 影响的范围, 好比: route, component, utils, build...
subject: commit 的概述, 建议符合 50/72 formatting
body: commit 具体修改内容, 能够分为多行, 建议符合 50/72 formatting
footer: 一些备注, 一般是 BREAKING CHANGE 或修复的 bug 的连接.

这样一个符合规范的 commit message, 就好像是一份邮件.bash

git commit 模板

若是你只是我的的项目, 或者想尝试一下这样的规范格式, 那么你能够为 git 设置 commit template, 每次 git commit 的时候在 vim 中带出, 时刻提醒本身:

修改 ~/.gitconfig, 添加:

[commit]
template = ~/.gitmessage
复制代码

新建 ~/.gitmessage 内容能够以下:

# head: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty (eg. if the change is a global or difficult to assign to a single component)
# - subject: start with verb (such as 'change'), 50-character line
#
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# footer: 
# - Include a link to the ticket, if any.
# - BREAKING CHANGE
#
复制代码

Commitizen: 替代你的 git commit

咱们的目标仍是要经过工具生成和约束, 那么如今就开始吧.

commitizen/cz-cli, 咱们须要借助它提供的 git cz 命令替代咱们的 git commit 命令, 帮助咱们生成符合规范的 commit message.

除此以外, 咱们还须要为 commitizen 指定一个 Adapter 好比: cz-conventional-changelog (一个符合 Angular团队规范的 preset). 使得 commitizen 按照咱们指定的规范帮助咱们生成 commit message.

全局安装

npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
复制代码

主要, 全局模式下, 须要 ~/.czrc 配置文件, 为 commitizen 指定 Adapter.

项目级安装

npm install -D commitizen cz-conventional-changelog
复制代码

package.json中配置:

"script": {
    ...,
    "commit": "git-cz",
},
 "config": {
    "commitizen": {
      "path": "node_modules/cz-conventional-changelog"
    }
  }
复制代码

若是全局安装过 commitizen, 那么在对应的项目中执行 git cz or npm run commit 均可以.

效果以下:

自定义 Adapter

也许 Angular 的那套规范咱们不习惯, 那么能够经过指定 Adapter cz-customizable 指定一套符合本身团队的规范.

全局或项目级别安装:

npm i -g cz-customizable
or
npm i -D cz-customizable
复制代码

修改 .czrc 或 package.json 中的 config 为:

{ "path": "cz-customizable" }
or
  "config": {
    "commitizen": {
      "path": "node_modules/cz-customizable"
    }
  }
复制代码

同时在~/ 或项目目录下建立 .cz-config.js 文件, 维护你想要的格式: 好比个人配置文件: leohxj/.cz-config

效果以下:

Commitlint: 校验你的 message

commitlint: 能够帮助咱们 lint commit messages, 若是咱们提交的不符合指向的规范, 直接拒绝提交, 比较狠.

一样的, 它也须要一份校验的配置, 这里推荐 @commitlint/config-conventional (符合 Angular团队规范).

安装:

npm i -D @commitlint/config-conventional @commitlint/cli
复制代码

同时须要在项目目录下建立配置文件 .commitlintrc.js, 写入:

module.exports = {
  extends: [
    ''@commitlint/config-conventional''
  ],
  rules: {
  }
};
复制代码

针对自定义的 Adapter 进行 Lint

若是你像我同样, 使用的是自定义的 commitizen adapter, 那么你须要:

npm i -D commitlint-config-cz @commitlint/cli
复制代码

.commitlintrc.js 中写入:

module.exports = {
  extends: [
    'cz'
  ],
  rules: {
  }
};
复制代码

结合 Husky

校验 commit message 的最佳方式是结合 git hook, 因此须要配合 Husky.

npm i husky@next
复制代码

package.json 中添加:

"husky": {
    "hooks": {
      ...,
      "commit-msg": "commitlint -e $GIT_PARAMS"
    }
  },
复制代码

效果以下:

standard-version: 自动生成 CHANGELOG

经过以上工具的帮助, 咱们的工程 commit message 应该是符合 Angular团队那套, 这样也便于咱们借助 standard-version 这样的工具, 自动生成 CHANGELOG, 甚至是语义化的版本号(Semantic Version).

安装使用:

npm i -S standard-version
复制代码

package.json 配置:

"scirpt": {
    ...,
    "release": "standard-version"
}
复制代码

PS: standard-version 有不少其余的特性, 这里不过多涉及, 有兴趣的同窗自行尝试.

最后

commit message 的规范性很重要, 可是是否须要像本文这样强制限制, 每一个团队和我的都有本身的想法, 可是我的认为: 好的习惯, 受益终身.