introduction
In the daily development work, we usually use git to manage the code. When we make some changes to the code, we can submit the code through git commit.
Git stipulates that the submission information must be written when submitting, which can be saved in the commit history as a change description for easy backtracking. The standard log is not only helpful for others to review, but also can effectively output changelog, and even greatly improve the R & D quality of the project.
But in daily work, most of the students for log information are simple writing, not very good attention, this for the project management and maintenance, is no doubt unfriendly. This article is mainly combined with my own experience to share with you some specifications of GIT commit, so that your log is not only “good-looking” but also “practical”.
Why regulate git commit
I’ve been talking about standardizing the commit format, so why do I do that?
Let’s take a look at a non-standard commit record
After reading what you feel and what you write (inner OS), this kind of commit information is undoubtedly a fatal blow for people who want to get effective information from it.
Let’s take a look at a popular one in the communityAngular specificationCommit record of:
Is it clear at a glance?
In the figure above, the commit information of this specification first provides more historical information for quick browsing. Secondly, some commit (such as document changes) can be filtered to find information quickly.
Now that I’m talking about itNorms of angular teamIt is a popular commit specification in the community. What is it? Now let’s have a detailed and in-depth understanding.
Commit specification of angular team
Its message format is as follows:
<type>(<scope>): <subject>
//A blank line
<body>
//A blank line
<footer>They correspond to the three parts of commit messageHeader，BodyandFooter。
Header
The header section has only one line, including three fields:type(required)scope(optional) andsubject(required).
-
type: used to describe the type of commit. Generally, there are the following types:Feature: new feature Fix: fix bugs Docs: only the document has been modified, such as readme.md Style: just modify the format, such as comma, indent, space, etc. Do not change the code logic. Refactor: code refactoring, no new features or bug fixes Perf: optimization related, such as improving performance, user experience, etc. Test: test cases, including unit test and integration test. Chord: change the construction process, or add dependent libraries, tools, etc. Reverse: version rollback -
scope: used to describe the impact scope of commit, such as: views, component, utils, test -
subject: short description of commit purpose
Body
The specific description of this commit modification can be divided into multiple lines. As follows:
# body: 72-character wrapped. This should answer:
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
# initial commitFooter
Some remarks, usuallyBREAKING CHANGE(the current code is not compatible with the previous version) or fixed bug (close issue).
After a brief introduction of the above specification, let’s talk about itcommit.templateThat is, GIT submit information template.
Git submit information template
If your team has format requirements for the submitted information, you can create a file on the system and configure git to use it as the default template, so that the submitted information can follow the format more easily.
Configure the submit information template with the following command:
git config commit.template [template file name] // this command can only set the submission template of the current branch
git config — —global commit.template [template file name] // this command can set the global submission template. Note that there are two bars in front of globalnewly build.gitmessage.txt(template file) can be as follows:
# headr: <type>(<scope>): <subject>
# - type: feat, fix, docs, style, refactor, test, chore
# - scope: can be empty
# - 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 issue.
# - BREAKING CHANGE
#After reading the above, do you feel like I’m having trouble configuring it? It’s not easy to configure an almost perfect commit specification suitable for yourself and the team. However, the community also provides us with some auxiliary tools to help us submit. Let’s briefly introduce these tools.
commitizen（cz-cli）
commitizenIt is a tool that can create and submit information interactively. It helps us to establish the submission information step by step from type, and the specific effect is shown in the figure:
- First of all, point to the type you want through the up and down key control, corresponding to the type mentioned above
feat、fix、docs、perfEtc
- You will then be asked to select the documents affected by this submission:
- You will be asked to write a brief and detailed description of the submission:
- Finally, it will let you judge whether this submission is correct
BREAKING CHANGEOr associated with the openedissue:
After looking at the whole process of commit above, let’s see how to install it.
-
Installation in global environment:
Commitizen according to different
adapterConfigure commit message. For example, to use the commit message format of angular, you can installcz-conventional-changelog。#You need to install both commit and CZ conventional changelog, which is adapter $ npm install -g commitizen cz-conventional-changelog #Configure installed adapter $ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc #Use $ git cz -
Local project installation:
#Install commit $ npm install --save-dev commitizen #Next, install the adapter # for npm >= 5.2 $ npx commitizen init cz-conventional-changelog --save-dev --save-exact # for npm < 5.2 $ ./node_modules/.bin/commitizen init cz-conventional-changelog --save-dev --save-exact // package.json Add the commit command to the script field "scripts": { "commit": "git-cz" } // use $ npm run commit
commitlint
commitlintIs a submission verification tool. The principle is that the GIT hook can be used to verify the information before the actual git commit is submitted to the remote warehouse. Submitting information that does not conform to the rules will be prevented from being submitted to the remote warehouse.
Let’s take a look at the demo:
aboutConventional CommitsThe community has been sorted out@commitlint/config-conventionalPackage, we just need to install and enable it.
First, install commitlint and convention specification
npm install --save-dev @commitlint/cli @commitlint/config-conventionalAnd then in thepackage.jsonMedium configurationcommitlintscript:
"commitlint": {
"extends": [
"@commitlint/config-conventional"
]
},Of course, if you want to configure commitlint separately, you need to create a verification file
commitlint.config.jsOtherwise, the verification will fail
In order to execute commitlint every time we commit to check the message we input, we need to use a tool——husky。
Husky is an enhancedgit hookTools. It can be executed in all phases of GIT hook, and we can do it in package.json NPM script configured in.
First install husky:
npm install --save-dev huskyAnd then in thepackage.jsonMedium configurationcommitmsgscript:
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},Come here,commitlintThe configuration is complete ～
gitmoji-cli
Usually, when chatting with friends, we will use expression packs, such as. The appearance of expression pack makes our communication with friends more interesting. If you can use the expression package when git submits a commit, it will make every commit more intuitive and easier to maintain.
gitmojiIt’s a plug-in that can realize this function. Let’s feel it first
Do you feel cool~~
actuallygitmojiIt is very simple to use
#Installation
npm i -g gitmoji-cli
#Use
Git commit - M ': bug: problem fix'Let’s take a look at the official example:
Are you ready to try?
Gitmoji project address
Examples of using gitmoji
After reading this article, do you feel that it’s very important for yougit commit messageHave you got a new understanding? Use these in your project to make your commit more standard. At the same time, don’t forget to addemojioh
Finally, a previous project configuration for git commit is attachedpackage.jsonFor reference:
{
"name": "ts-axios",
"version": "0.0.0",
"description": "",
"keywords": [],
"main": "dist/ts-axios.umd.js",
"module": "dist/ts-axios.es5.js",
"typings": "dist/types/ts-axios.d.ts",
"files": [
"dist"
],
"author": "fengshuan <[email protected]>",
"repository": {
"type": "git",
"url": ""
},
"license": "MIT",
"engines": {
"node": ">=6.0.0"
},
"scripts": {
"dev": "node examples/server.js",
"lint": "tslint --project tsconfig.json -t codeFrame 'src/**/*.ts' 'test/**/*.ts'",
"prebuild": "rimraf dist",
"build": "tsc --module commonjs && rollup -c rollup.config.ts && typedoc --out docs --target es6 --theme minimal --mode file src",
"start": "rollup -c rollup.config.ts -w",
"test": "jest --coverage",
"test:watch": "jest --coverage --watch",
"test:prod": "npm run lint && npm run test -- --no-cache",
"deploy-docs": "ts-node tools/gh-pages-publish",
"report-coverage": "cat ./coverage/lcov.info | coveralls",
"commit": "git-cz",
"semantic-release": "semantic-release",
"semantic-release-prepare": "ts-node tools/semantic-release-prepare",
"precommit": "lint-staged",
"travis-deploy-once": "travis-deploy-once"
},
"husky": {
"hooks": {
"commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
}
},
"lint-staged": {
"{src,test}/**/*.ts": [
"prettier --write",
"git add"
]
},
"config": {
"commitizen": {
"path": "node_modules/cz-conventional-changelog"
}
},
"jest": {
"transform": {
".(ts|tsx)": "ts-jest"
},
"testEnvironment": "node",
"testRegex": "(/__tests__/.*|\.(test|spec))\.(ts|tsx|js)$",
"moduleFileExtensions": [
"ts",
"tsx",
"js"
],
"coveragePathIgnorePatterns": [
"/node_modules/",
"/test/"
],
"coverageThreshold": {
"global": {
"branches": 90,
"functions": 95,
"lines": 95,
"statements": 95
}
},
"collectCoverageFrom": [
"src/*.{js,ts}"
]
},
"prettier": {
"semi": false,
"singleQuote": true
},
"commitlint": {
"extends": [
"@commitlint/config-conventional"
]
},
"devDependencies": {
"@commitlint/cli": "^7.1.2",
"@commitlint/config-conventional": "^7.1.2",
"@types/jest": "^23.3.2",
"@types/node": "^10.11.0",
"body-parser": "^1.19.0",
"colors": "^1.3.2",
"commitizen": "^3.0.0",
"coveralls": "^3.0.2",
"cross-env": "^5.2.0",
"cz-conventional-changelog": "^2.1.0",
"express": "^4.17.1",
"husky": "^1.0.1",
"jest": "^23.6.0",
"jest-config": "^23.6.0",
"lint-staged": "^8.0.0",
"lodash.camelcase": "^4.3.0",
"prettier": "^1.14.3",
"prompt": "^1.0.0",
"replace-in-file": "^3.4.2",
"rimraf": "^2.6.2",
"rollup": "^0.67.0",
"rollup-plugin-commonjs": "^9.1.8",
"rollup-plugin-json": "^3.1.0",
"rollup-plugin-node-resolve": "^3.4.0",
"rollup-plugin-sourcemaps": "^0.4.2",
"rollup-plugin-typescript2": "^0.18.0",
"semantic-release": "^15.9.16",
"shelljs": "^0.8.3",
"travis-deploy-once": "^5.0.9",
"ts-jest": "^23.10.2",
"ts-loader": "^6.1.1",
"ts-node": "^7.0.1",
"tslint": "^5.11.0",
"tslint-config-prettier": "^1.15.0",
"tslint-config-standard": "^8.0.1",
"tslint-loader": "^3.5.4",
"typedoc": "^0.12.0",
"typescript": "^3.0.3",
"webpack": "^4.40.2",
"webpack-dev-middleware": "^3.7.1",
"webpack-hot-middleware": "^2.25.0"
}
}
last
You can focus on my official account, front end forest. I will issue some front-end articles related to the large front end and actual combat summary in the daily development process. Of course, I am also an active contributor to the open source community, GitHub address https://github.com/Jack-cool Welcome star!!!
