Git commit specification that you may have ignored

Time:2021-1-14

Git commit specification that you may have ignored

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

Git commit specification that you may have ignored

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:

Git commit specification that you may have ignored

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 messageHeaderBodyandFooter

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 commit

Footer

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 global

newly 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 abovefeatfixdocsperfEtc

Git commit specification that you may have ignored

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

Git commit specification that you may have ignored

  • You will be asked to write a brief and detailed description of the submission:

Git commit specification that you may have ignored

  • Finally, it will let you judge whether this submission is correctBREAKING CHANGEOr associated with the openedissue:

Git commit specification that you may have ignored

After looking at the whole process of commit above, let’s see how to install it.

  • Installation in global environment:

    Commitizen according to differentadapterConfigure 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:

Git commit specification that you may have ignored

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-conventional

And 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 filecommitlint.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 husky

And 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

Git commit specification that you may have ignored

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:

Git commit specification that you may have ignored

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!!!

Git commit specification that you may have ignored

Recommended Today

General method of Tkinter (21) components

method explain after(delay_ms, callback=None, *args) At least delay_ Ms after calling callback, no callback, equivalent time.sleep (); returns an ID to cancel after_ The cancel () method uses after_cancel(id) Cancel the callback of after method call after_idle(func, *args) Similar to the after method, but called when there is no event idle bell() A beep bind(sequence=None, […]