Git is the most popular version control tool on the market. A well-written commit message can greatly improve the efficiency of code maintenance. However, due to the lack of constraints on the commit message in daily development, the content is random, the quality is uneven, the readability is low, and it is difficult to maintain. It is imminent to introduce the commit message specification into the project.
What standard?
The most popular solution on the market now is the Conventional Commits, which is inspired by the Angular submission guidelines and is largely based on it. The contract submission specification is a lightweight contract based on the submission message. It provides a set of simple rules for creating a clear submission history; this makes it easier to write automated tools based on specifications. This agreement is consistent with SemVer, which describes new features, bug fixes, and disruptive changes in the submission information. Its message format is as follows:
<类型>[可选的作用域]: <描述>
[可选的正文]
[可选的脚注]Quick Start
1. Install commitizen & cz-conventional-changelog globally
commitizen is a tool for writing qualified commit messages, used to replace git commit instructions, and the cz-conventional-changelog adapter provides conventional-changelog standards (conventional submission standards). Based on different needs, different adapters can also be used.
npm install -g commitizen cz-conventional-changelog
echo '{ "path": "cz-conventional-changelog" }' > ~/.czrcAfter installation, you can directly use git cz to replace git commit.
In the global mode, the ~/.czrc configuration file is required to specify the Adapter for commitizen.
2. Install commitlint & husky in the project
commitlint is responsible for format verification of commit message, and husky is 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 -DCommitlint can only do format specifications and cannot touch the content. We can only rely on ourselves to control the quality of content.
3. Add the corresponding configuration
Create commitlint.config.js
# In the same path as package.json
echo 'module.exports = {extends: ["@commitlint/config-conventional"]};' > ./commitlint.config.js
引入husky
# package.json
...,
"husky": {
"hooks": {
"commit-msg": "commitlint -e $GIT_PARAMS"
}
}4. Use
Execute git cz to enter interactive mode, fill in one by one according to 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>)The format of the generated commit message is as follows:
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>After filling in, Husky will call commitlint to verify the format of the message. By default, type and subject are required.
The option of any git commit command can be used on the git cz command, such as git cz -a
Commit message specifications are used in rrd-fe
In view of the current situation of the team, after discussion, we formulated the filling rules for each part of the commit message.
1. type
type is required, used to specify the type of commit. It has agreed on the two main types of feat and fix, and the five special types of docs, style, build, refactor, and revert. The remaining types are temporarily not used.
# 主要type
feat: 增加新功能
fix: 修复bug
# 特殊type
docs: 只改动了文档相关的内容
style: 不影响代码含义的改动，例如去掉空格、改变缩进、增删分号
build: 构造工具的或者外部依赖的改动，例如webpack，npm
refactor: 代码重构时使用
revert: 执行git revert打印的message
# 暂不使用type
test: 添加测试或者修改现有测试
perf: 提高性能的改动
ci: 与CI（持续集成服务）有关的改动
chore: 不修改src或者test的其余修改，例如构建过程或辅助工具的变动When a change includes the main type and the special type, the main type is uniformly adopted.
2. scope
Scope is also a required item, used to describe the scope of the change, the format is project name/module name, for example: node-pc/common rrd-h5/activity, and we-sdk does not need to specify the module name. If you modify multiple modules at one commit, it is recommended to split them into multiple commits for better tracking and maintenance.
3. body
The body fills in a detailed description, mainly describing the situation before the change and the motivation for the modification. There is no requirement for small modifications, but the body must be added for explanation of major needs, updates, etc.
4. break changes
Break changes indicate whether there are destructive modifications. Changes involving break changes must indicate this item, such as version upgrade, interface parameter reduction, interface deletion, migration, etc.
5. affect issues
Affect issues indicate whether a problem is affected. For example, when we use jira, we can fill in the JIRA_ID that it affects in the commit message. To enable this function, we need to get through jira and gitlab first. Reference document: docs.gitlab.com/ee/user/pro...
For example:
re #JIRA_ID
fix #JIRA_IDExample
- Complete commit message example
- Corresponding git log
If you like this article, I hope you can move your little hand to read it and forward it to support a wave.
Renrendai Big Front-end Technology Center
juejin.im/post/5d0b3f8c6fb9a07ec07fc5d0
程序员
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。