1. Why do we need norms?

It’s the same with programming.

If you have a project and you write it yourself from start to finish, you can write it however you want and no one can interfere with you. But in a team environment where everyone is individual, the code will be a mess and the project will be ruined. Both development and future maintenance will be a disaster.

At this time, someone put forward why not unify the standard, we all follow this standard. As a result, ESLint, JSHint and other code tools have mushroomed and become essential for project construction.

The Git Commit specification may not be that dramatic, but if you see a bunch of stupid commits during a rollback, you’ll probably get upset. Therefore, strictly abide by the norms, self-interest.

2. Specific rules

Let’s start with the formula:

<type>(<scope>): <subject>

type

Only the following seven identifiers are allowed to describe the commit category.

Feat: New Feature

Fix: fix

-Dan: Well, there are bugdocs.

Style: format (changes that do not affect code execution)

Refactor: refactoring (i.e. code changes that are not new features or bug fixes)

Test: Adds a test

Chore: Changes to the build process or helper

scope

Use to indicate the scope of the commit impact, such as the data layer, control layer, view layer, and so on, depending on the project.

subject

Is a short description of the commit purpose, which cannot exceed 50 characters.

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 (.)

Three, exception handling

Let’s start with this exception alert:

INVALID COMMIT MSG: does not match "<type>(<scope>): <subject>" ! 
jartto:fix bug 
Copy the code

The reason for this warning is that there are two problems with my submission:

First, keywords outside the specification are used;

Second, very detailed questions, jartto: after the missing space;

Only then did I recall that the submission had been failing at that time, so I forced the submission directly, so all subsequent submissions would have this exception. The general idea is:

Your previous Commit failed ~ your previous Commit failed ~ your previous Commit failed

This is very annoying, we can only go to the previous error correction, so how to operate?

4. How to modify the previous COMMIT information?

It’s not complicated, we just need to do this:

1. Store the working state irrelevant to the current branch temporarily

git stash 
Copy the code

2. Move the HEAD to the COMMIT that needs to be modified

git rebase 9633cf0919^ --interactiveCopy the code

3. Find the commit that needs to be modified and change the first line of pick to Edit

4. Start working on your bugs

Git add adds the change file to the staging

Git commit — amend adds changes to commit

Git rebase — continue move HEAD back to the latest commit

8. Restore your previous working status

git stash popCopy the code

Commit (); Commit ()

V. Use in the project

The question then arises, why do I submit with a warning, and how do I do this?

In this case, we need a Node plugin called validate-commit-msg to check whether the commit message in the project is normal.

1. First, install the plug-in:

npm install --save-dev validate-commit-msg 
Copy the code

2. Use method 1, create.vcMRc file:

{ 
  "types": ["feat"."fix"."docs"."style"."refactor"."perf"."test"."build"."ci"."chore"."revert"]."scope": { 
    "required": false."allowed": ["*"]."validate": false."multiple": false 
  }, 
  "warnOnFail": false."maxSubjectLength": 100, 
  "subjectPattern": "+"."subjectPatternErrorMsg": "subject does not match subject pattern!"."helpMessage": ""."autoFix": false 
} 
Copy the code

3. Usage 2: Write package.json

{ 
  "config": { 
    "validate-commit-msg": { 
      /* your config here */ 
    } 
  } 
}
Copy the code

4. But what if we want to use the Ghooks hook function automatically?

{..."config": { 
    "ghooks": { 
      "pre-commit": "gulp lint"."commit-msg": "validate-commit-msg"."pre-push": "make test"."post-merge": "npm install"."post-rewrite": "npm install",... }}... }Copy the code

There are a lot of things you can do in Ghooks, not just validate-commit-msg.

See validate-commit-msg for more details

The role of the Commit specification

Provide more information to facilitate troubleshooting and rollback;

Filter keywords, quick positioning; Convenient document generation;

Generate Change log

As mentioned above in generating documentation, it would be easy if our submissions followed the specifications. The generated document consists of the following three parts:

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.

Use the Conventional Changelog tool to generate Changelog:

npm install -g conventional-changelog 
cd jartto-domo 
conventional-changelog -p angular -i CHANGELOG.md -wCopy the code

For ease of use, you can write it to the scripts field of package.json.

{ 
  "scripts": { 
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -w -r 0"}}Copy the code

This way, it’s easy to use:

npm run changelog

So we’ve got all our questions figured out. Cheers

Eight, summary

After reading this article, will you still be so Bohemian? Do you still write Commit as you please? Git commit -m “Hello world” commit

The answer is no, because with the hook function, you have no chance, otherwise it would be endless to restore Commit. This can lead to good submission habits