Git Commit

Git commit is used to record changes to the repository



In daily development, the most common use of Git commands is Git commit. However, the specification of the commit message can improve the efficiency of code maintenance and upgrade, and can quickly and easily troubleshoot problems. The specification of the Commit message is then very important

Git Commit message specification

The most commonly used specification is the Angular specification, which is also used by Alibaba and Didi.

You can see the format of the Commit Message in Angular documentation

<type>(<scope>): <subject> <body>Copy the code

According to the document, there are three parts, respectively

  1. Header message Header, type: contains the type (required), scope: scope (affected module/file) (optional), subject: short description (required)
  2. Body Body, fill in a detailed description of this change
  3. Footer: This parameter is required when the following two situations occur
    1. Breaking changes: Whether major changes occur, such as version upgrade, interface upgrade, architecture adjustment, project separation, migration and merger
    2. Affect Issues: Whether the submission affects a certain issue

Type The types are as follows:

  • Feat: New Feature
  • Fix: Fixes bugs
  • Improvement: Improvements to existing functionality
  • Docs: Document changes (eg: MD file)
  • Style: changes in code format (note: not style, refers to code Spaces, indentation, line breaks, punctuation, etc.)
  • Refactor: refactoring
  • Perf: Performance Optimization
  • Test: tests file updates
  • Build: Build system or package dependent update (eg: gulp, NPM, broccoli)
  • Ci: CL configuration, script files, etc updates (eg: Travis Continuous integration service,)
  • Chore: Non-SRC or test file updates
  • Revert: commit Rollback

Commitizen tool: Provides a compliant Git commit specification

Commitizen is a commit message tool that generates standard specifications.

Operating environment: Node > 6.0

Although the tool is compatible with lower versions of Node, the tool was tested on node10.x and 12.x, so it is best to use an environment larger than Node6.0

Commitizen installation

NPM install -g commitizen or install NPM install-save-dev commitizen locallyCopy the code


Cz-xconventional – Changelog adapter installation (Use a script to generate a COMMIT document)

npm install -g cz-conventional-changelogCopy the code

After the previous installation, add the. ZCRC configuration file to the root directory

{ "path": "cz-conventional-changelog" }Copy the code

The commitizen command will then automatically add the corresponding configuration to package.json

// Run the commitizen init cz-xconventional -changelog --save-dev --save-exact command or use yarn Commitizen init Cz-conventional - Changelog --yarn --dev --exact //package.json The following information is automatically generated"config": {
    "commitizen": {
      "path": "cz-conventional-changelog"}}Copy the code

The git cz command is used to replace git commit with git commit.



Select Build for introducing new dependencies

Fill in/select in turn

  • Name of the component or file that is changed
  • Short description (79 characters or less)
  • A detailed description
  • Are there any major changes
  • Whether this commit affects/fixes a problem



The commit information is clearly visible from the COMMIT record on the GitLab repository




If git CZ selects “breaking changes”, there will be one more line of description about “major changes” that needs to be entered



There is also a line of BREAKING CHANGE description on the warehouse COMMIT




If the code you submit involves fixing issues, you can choose whether it affects issues by entering the issues information (e.g. “fix #123”, “re #123”.)



The submission record of the warehouse will be automatically associated with issues. Click #1 to jump to the Issues page. In this case, the status of warehouse Issues cannot be changed. If the status of issues needs to be affected, you need to install and configure JIRA




Generate the Change log

If all of our commits are in Angular format, execute the following command to generate Changelog.md in the root directory. The generated document contains three modules: feature, bug and Breaking change

// This command will not override the previous ChangelogInstead, it adds the changelog. md header with the change from the last publication to the current xconventional - CHANGELOG -p angular-i Changelog. md-sCopy the code

If you want to generate all the change logs, you can execute the following command

conventional-changelog -p angular -i CHANGELOG.md -w -r 0Copy the code


To avoid entering such a long command line each time, you can define commands in package.json



NPM run Changelog generates all changes NPM run allChangelogCopy the code

The generated log files are as follows, which can be easily seen when the new changes are made and can be directly linked to the corresponding COMMIT-ID of the GitLab repository



There is one caveat: before generating changelog logs, you need to update the package.json version number with the following command. If you do not do this, you will end up with the same log with each commit

NPM Version Indicates the version numberCopy the code

Git commit format verification

Commit specifications require validation, commitLint, HusKY, etc

Commitlint: Format used to configure the commit message

Husky is a git hook management tool that implements most of the git hooks.

Run environment: Node >= 8.6.0 and Git >= 2.13.0.


NPM install --save-dev @commitlint/{cli,config-conventional} // Create a commitlint configuration fileecho "module.exports = {extends: ['@commitlint/config-angular']};"> commitlint.config.js //Husky install NPM --save-dev Husky // Add Husky configuration in package.json, level with script"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"}}Copy the code

test

If the commit does not conform to the specification, the COMMIT will be intercepted



A commit message that matches the verification is passed



purpose

  • Unify the development team’s COMMIT specification to facilitate subsequent code maintenance
  • Provide valid historical commit information to other developers