Git commit message specification

git is now available in the most popular version control tool, good writing commit message can greatly improve the efficiency of code maintenance. But in the daily development due to lack of constraints on the commit message, leading to fill in the contents of arbitrary, uneven quality, low readability is also difficult to maintain. Introducing commit message specification in the project is imminent.

What norms?

Now the market is more popular programs 约定式提交规范( Conventional Commits), which has been Angular提交准则inspired, and to a large extent be based upon. 约定式提交规范It is based on a lightweight agreed to submit the message. It provides a set of simple rules to submit a clear history for creating; it makes writing easier norm-based automation tools. This convention and SemVerconsistent, describes the new features, bug fixes and destructive changes in the submitted information. Its message format is as follows:

<类型>[可选的作用域]: <描述>

[可选的正文]

[可选的脚注]
复制代码

Quick Start

Installation globally commitizen & cz-conventional-changelog

commitizenIs qualified to write a commit messagetool used in place of git committhe instruction, the cz-conventional-changelogadapter provides conventional-changelog standard (standard convention commit). Based on different needs, you can also use a different adapter.

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

After installation, it can be used directly git czinstead git commit.

Global mode, you need to ~/.czrcconfigure the file as commitizenspecified Adapter.

2. Project within the installation commitlint & husky

commitlintResponsible for commit messagethe format check, huskyis responsible for providing easier to use git hook.

Use npm

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

Use yarn

yarn add husky @commitlint/config-conventional @commitlint/cli -D
复制代码

commitlintFormat specification can only do not touch the contents. For the quality of the content of the control can only rely on ourselves.

3. Add the corresponding configuration

createcommitlint.config.js

# In the same path as package.json

echo 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js
复制代码

Introducedhusky

# package.json

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

4. Use

Execution git czenters interactive mode, in order to fill in the prompts

1.Select the type of change that you're committing 选择改动类型 (<type>)

2.What is the scope of this change (e.g. component or file name)? 填写改动范围 (<scope>)

3.Write a short, imperative tense description of the change: 写一个精简的描述 (<subject>)

4.Provide a longer description of the change: (press enter to skip) 对于改动写一段长描述 (<body>)

5.Are there any breaking changes? (y/n) 是破坏性修改吗？默认n (<footer>)

6.Does this change affect any openreve issues? (y/n) 改动修复了哪个问题？默认n (<footer>)
复制代码

Generated commit message format is as follows:

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

After completed, huskyit will call commitlinton the message format check, default provisions typeand subjectis required.

Any git commitinstruction optioncan be used in git czthe instructions, e.g.git cz -a

Commit message specifications use the landing rrd-fe

For the case of teams currently use, we developed after discussions commit messagefill in each part of the rule.

1. type

typeIs required, specifies the type of commit, agreed feat, fixtwo 主要type, and docs, style, build, refactor, revert five 特殊type, 其余typenot in use.

# 主要type
feat:     增加新功能
fix:      修复bug

# 特殊type
docs:     只改动了文档相关的内容
style:    不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build:    构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert:   执行git revert打印的message

# 暂不使用type
test:     添加测试或者修改现有测试
perf:     提高性能的改动
ci:       与CI（持续集成服务）有关的改动
chore:    不修改src或者test的其余修改，例如构建过程或辅助工具的变动
复制代码

When the primary changes include 主要typethe 特殊typetime, uniform application 主要type.

2. scope

scopeAlso is required to describe the scope of change in the format of the project name / module name, for example: node-pc/common rrd-h5/activity, and we-sdkwithout specifying the module name. If a commit modify multiple modules, the proposed split into multiple commit, in order to better track and maintain.

3. body

bodyFill out a detailed description of the main description 改动之前的情况and 修改动机, with a minor change is not required, but significant demand, etc. must be updated to add body for illustration.

4. break changes

break changesIt indicates whether or not a destructive modifications, alterations involving break changes must indicate that, similar to the version upgrades, reducing the interface parameters, remove the interface and migration.

5. affect issues

affect issuesIndicates whether the impact of a problem. For example we use jira, we commit messagecan fill their influence in JIRA_ID, to open the function you need to get through jirawith gitlab. Reference documents: docs.gitlab.com/ee/user/pro...

Fill in ways such as:

re #JIRA_ID
fix #JIRA_ID
复制代码

Examples

Complete commit message example
Corresponding git log

The last convention, we welcome the star we all lending large front-end team blog , all articles will be updated simultaneously to know almost columns and Nuggets account , week we will share a few high-quality large front-end technical articles. If you enjoyed this article, I hope to give a little hand moving dynamic praise.