Git commit specifications that you might ignore

Has been a loyal user of ESLint and understands the importance of specifications. However, I was driven crazy by the Git Commit specification during the transition to a new project. Only to realize their negligence, so they have the idea to explore.

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

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

Three, exception handling

Let’s start with this exception alert:

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

The reason for this warning is that there are two problems with my submission: first, the use of non-canonical keywords; 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?

git stashCopy the code

git rebase 9633cf0919^ --interactiveCopy the code

git stash popCopy the code

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

ghooks
validate-commit-msg

See validate-commit-msg for more details

The role of the Commit specification

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 changelogCopy the code

Here we have all our questions figured out 🍻Cheers ~

Eight, summary