The introduction

In daily development work, we usually use Git to manage the code, when we make some changes to the code, you can commit the code through Git commit.

Git specifies that commit information must be written at commit time. This information is stored in the commit history as a change description for easy traceability. The standard log is not only helpful for others to review, but also can effectively output CHANGELOG, and even greatly improve the quality of project research and development.

However, in daily work, most students simply write log information and do not pay much attention to it, which is undoubtedly unfriendly to project management and maintenance. In this article, I will share with you some guidelines for making your Git commit not only “nice” but also “useful”.

Why standardize Git Commit

You’ve been talking about standardizing the COMMIT format, so why?

Let’s start with a less formal commit record:

This commit message can be a fatal blow to anyone trying to get useful information out of it.

Let’s look at the commit record of one of the most popular Angular specifications in the community:

Is it clear at a glance?

The commit information for the specification shown above first provides more historical information for quick browsing. Second, certain commits (such as document changes) can be filtered to make it easy to find information quickly.

Now that the Angular team specification is the most popular commit specification in the community, what is it? Let’s take a closer look.

Commit specification for the Angular team

Its message format is as follows:

<type>(<scope>) :<subject>/ / an empty line<body>/ / an empty line<footer>
Copy the code

The three parts of the Commit message correspond to the Header, Body, and Footer.

Header

The Header section is a single line with three fields: Type (required), scope (optional), and subject (required).

  • Type: Indicates the type of commit. There are generally the following kinds:

    Feat. Readme.md style feat. Readme.md style. Do not change the code logic. Refactor: code refactoring, no new features or bug fixes Perf: optimization related, such as improved performance, user experience, etc.test: Test cases, including unit tests and integration tests. Chore: Change the build process, or add dependency libraries, tools, etc. Revert: Version rollbackCopy the code

  • Scope: specifies the scope of the commit effect, for example: views, Component, utils, test…

  • Subject: Short description of the commit destination

Body

The detailed description of the 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 commit
Copy the code

Footer

Some notes, usually links to BREAKING CHANGE(the current code is not compatible with the last version) or bug fixes (closing issues).

Commit. Template: Git commit template

Git commit information template

If your team has formatting requirements for submissions, you can create a file on your system and configure Git to use it as the default template to make it easier to format your submissions.

To configure the submission template, run the following command:

Git config -- global commit. Template [template name] git config -- global commit. Notice that global is preceded by two barsCopy the code

Create.gitmessage. TXT (template file) with the following contents:

# 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
#
Copy the code

If you’re like me, it’s not easy to configure a near-perfect COMMIT specification for yourself and your team. However, the community has provided us with some tools to help with submission. Here’s a brief overview of these tools.

Commitizen (cz – cli)

Commitizen is a tool for creating submissions interactively. It helps us set up the submission information step by step, starting with Type, as shown in the following figure:

  • Feat, Fix, Docs, Perf, and so on

  • You will then be asked to select the files affected by this submission:

  • You will be asked to write a short and detailed submission description:

  • At the end you will be left to decide whether this submission isBREAKING CHANGEOr an association has been openedissue:

After looking at the commitizen process above, let’s look at how to install it.

  • Installation in global environment:

    Commitizen configures the Commit message according to the adapter. For example, to use Angular’s commit Message format, you can install CZ-Xconventional – Changelog.

    Commitizen and CZ-Conventional - Changelog need to be installed at the same time
$ npm install -g commitizen cz-conventional-changelog
Configure the installed Adapter
$ echo '{ "path": "cz-conventional-changelog" }' > ~/.czrc
# use
$ git cz

Copy the code

  • Local project installation:

    Install --save-dev commitizen # for NPM >= 5.2 $NPX Commitizen 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 script add commit command "scripts": {"commit": "git-cz" } // use $ npm run commitCopy the code

commitlint

Commitlint is a commit validation tool. The idea is that you can use git hooks to validate information before the actual Git commit is committed to a remote repository. Submission of information that does not conform to the rules will be blocked from submission to the remote repository.

Let’s take a look at the demo:

For the Conventional Commits specification, the community has the @commitlint/ config-Conventional package ready, and we simply need to install and enable it.

Install commitLint and Conventional specifications first:

npm install --save-dev @commitlint/cli @commitlint/config-conventional
Copy the code

Then configure the Commitlint script in package.json:

"commitlint": {
    "extends": [
      "@commitlint/config-conventional"]},Copy the code

Of course, if you want to configure commitLint separately, you need to set up the validation file commitlint.config.js; otherwise, the validation will fail

In order to execute commitLint on each commit to check our input message, we also need a tool — Husky.

Husky is an enhanced Git hook tool. The NPM script that we configured in package.json can be executed at various stages of git hook.

First install Husky:

npm install --save-dev husky
Copy the code

Then configure the Commitmsg script in package.json:

"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
 },
Copy the code

At this point, commitlint is configured

gitmoji-cli

When we are chatting with friends, we are bound to use emojis, such as. The appearance of emojis has made the communication between us and our friends more interesting. Git commits to memes. Git commits to memes. Git commits to memes with memes.

Gitmoji is a plug-in that can do just that, so let’s get a feel for it

Do you feel cool~~

Gitmoji is actually quite simple to use:

# installation
npm i -g gitmoji-cli
# use
git commit -m ': a bug: fix problem'

Copy the code

Let’s take a look at the official example:

Are you itching to try it?

Gitmoji project address

Gitmoji use example

Git Commit message: Git Commit Message: Git Commit Message Go ahead and apply this to your projects, make your commit more formal, and don’t forget to add emojis to your logs!

Package. json for git commit configuration

{
  "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"}}Copy the code

The last

You can follow my public account of the same name [Front-end Forest], where I will regularly post some cutting-edge articles related to the big front-end and summarize the actual combat in the daily development process. Of course, I am also an active contributor to the open source community, github https://github.com/Jack-cool, welcome star!!