The premise
Long-term submission of code is not standard, resulting in their own confusion when viewing.
The canonical Commit Message makes it easy to quickly browse and look for version differences.
1. Commit Message format
The Commit message consists of three parts: Header, Body, and Footer
<type>(<scope>): <subject>
/ / an empty line
<body>
/ / an empty line
<footer>
// Space after the colon
// eg: feat(view): Add case based on Vue and Vuex
Copy the code
The Header is required, and the Body and Footer can be omitted.
1.1, the Header
The Header section is a single line with three fields: Type (required), scope (optional), and subject (required).
1.1.1 type
Type Indicates the commit type. Only the following seven identifiers can be used.
- Feat: new features
- Fix: fix the bug
- Docs: document
- Style: format (changes that do not affect code execution)
- Refactor: refactoring
- Test: Adds a test
- Chore: Changes to the build process or helper
If type is feat and fix, the commit will definitely appear in the Change log. In other cases, it is not recommended.
1.1.2 the scope
Scope specifies the scope of the commit, such as the data layer, control layer, attempt layer, and so on, depending on the project.
1.1.3 subject
Subject is a short description of the commit purpose, no more than 50 characters long.
- Start with a verb and use the present first-person tense such as’ change ‘rather than’ changed ‘or’ changes’
- The first letter is lowercase
- Ending without a period (.)
1.2, the Body
The Body section is a detailed description of the commit, broken into multiple lines.
- Use the present tense of the first person, such as “change” instead of “changed” or “changes”.
- Explain the motivation for the code change and how it compares to previous behavior.
1.3, Footer
The Footer section is only used in two cases.
- Incompatible variation
- Close the Issue
2. Normative methods
Git Commit check with cimmitLint and husky. Git commit check will be performed before the check succeeds.
2.1、 commitlint
// 项目目录下安装
npm i commitlint @commitlint/config-conventional --save-dev
Copy the code
// In the project directory, create a configuration file commitlint.config.js
module.exports = {
extends: ['@commitlint/config-conventional'].rules: {
// type Type definition
'type-enum': [2.'always'["feat".// 新功能 feature
"fix"./ / fix the bug
"docs".// Document comments
"style".// Code format (changes that do not affect code execution)
"refactor".// Refactoring (neither adding new features nor fixing bugs)
"perf".// Performance optimization
"test".// Add tests
"chore".// Changes to the build process or accessibility tools
"revert"./ / back to back
"build" / / packaging
]],
// Subject case is not checked
// The auto-deployed BUILD ROBOT commit information is capitalized for distinction
'subject-case': [0]}};Copy the code
2.2, husky
npm i husky --save-dev
Copy the code
// Add to package.json file
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}}Copy the code
2.3, commitizen
Commitizen is a tool for writing qualified Commit messages.
NPM I Commitizen --save-dev // Initialize the project to use THE COMMitizen commxcom - Changelog adapter init cz-customizable --save-dev --save-exactCopy the code
// Add related configuration in package.json file
// Path may need to be changed
"config": {
"commitizen": {
"path": "./node_modules/cz-customizable"}}Copy the code
// In the project directory, create the configuration file.cz-config.js
'use strict';
module.exports = {
types: [{value: 'feat'.name: 'Feat: New Feature'},
{value: 'fix'.name: 'fix: fix'},
{value: 'docs'.name: 'docs: Document changes'},
{value: 'style'.name: 'style: code format (changes that do not affect code execution)'},
{value: 'refactor'.name: 'refactor: refactoring (neither adding features nor fixing bugs)'},
{value: 'perf'.name: 'PERF: Performance Tuning'},
{value: 'test'.name: 'test: add test '},
{value: 'chore'.name: 'chore: Changes to the Build process or accessories'},
{value: 'revert'.name: 'revert: 回退'},
{value: 'build'.name: 'build: package'}].// override the messages, defaults are as follows
messages: {
type: 'Please select submission type :'.// scope: 'Please enter the file modification scope (optional):',
// used if allowCustomScopes is true
customScope: 'Please enter modification scope (optional):'.subject: 'Please briefly describe submission (required):'.body: 'Please enter a detailed description (optional, to be optimized to remove, skip):'.// breaking: 'List any BREAKING CHANGES (optional):\n',
footer: 'Please enter the issue to close :'.confirmCommit: 'Confirm submission using the above information? (y/n/e/h)'
},
allowCustomScopes: true.// allowBreakingChanges: ['feat', 'fix'],
skipQuestions: ['body'.'footer'].// limit subject length, commitlint defaults to 72
subjectLimit: 72
};
Copy the code
Use git cz instead of git commit. At this point, options appear to generate a Commit Message that matches the format.
3. Automatically generate change log
If all the commits are in Angular format. When a new version is released, the Change log can be automatically generated by the script. The resulting document consists of the following three sections.
- New features
- Bug fixes
- Breaking changes.
Each section lists the associated Commits and has links to them. Of course, the resulting document allows manual modification, so you can add additional content before Posting.
Convention-changelog is a tool for generating Change log. Run the following command.
npm install -g conventional-changelog-cli --save-dev
Copy the code
// Add configuration to package.json
"scripts": {
"changelog": "conventional-changelog -p angular -i CHANGELOG.md -s"
}
Copy the code
In the future, simply run the following command.
npm run changelog
Copy the code
References:
[1]. Commitlint – Commit message and Change log [2]. Commitlint [3]. Super detailed Git submission specification introduction guide