Introduction of Git Hooks

In addition to code versioning, Git itself provides Git Hooks that allow you to perform custom actions before (after) commit and push.

In the root directory of every Git project, there is a hidden.git directory. The hooks directory provides a number of default hook scripts, which can be executed by removing the default.sample suffix.

usehuskyTransform the Git Hooks

The installation

npm install -D husky
Copy the code

After husky is installed, you can see the changes to the files in the.git/hooks directory:

Pre -* indicates the script that is run before an operation, and post-* indicates the script that is run after an operation.

configuration

Add the following configuration to package.json:

// package.json { "husky": { "hooks": { "pre-commit": "npm run lint", "pre-push": "npm test", "..." : "..." }}, "..." : "..." }Copy the code

Starting with 1.0.0, husky can be configured as.huskyrc,.huskyrc.json,.huskyrc.yaml, huskyrc.yml,.huskyrc.js or husky.config.js files.

// .huskyrc
{
  "hooks": {
    "pre-commit": "npm run lint"
  }
}
Copy the code

Now the NPM run lint command is run before each commit and the code cannot be committed if there is an error. PS: If it is a warning, a corresponding message will be displayed, but the submission can be successful.

uselint-stagedImprove the pre – commit

In the previous step, all code was checked before each commit. In large projects this can make submission slow. Also, it may cause someone else’s code to fail to commit our changes. Lint-staged versions now solve this problem by examining only the document that has been changed the next time each team member commits it.

The installation

npm install -D lint-staged
Copy the code

configuration

// package.json { "lint-staged": { "*.vue": "vue-cli-service lint", "*.js": "eslint", "*.less": "stylelint", "*.css": "stylelint", "*.scss": "stylelint", "*.md": "markdownlint" }, "..." : "..." }Copy the code
// .huskyrc
{
  "hooks": {
    "pre-commit": "lint-staged"
  }
}
Copy the code

Now, every time we submit, we only check our own changes, and no longer have to fix others’ errors 😁

usecommitlintStandardize the commit messages

The standard Commit message is easier to read and maintain, which can help the team review code and improve team efficiency. At the same time, it is convenient for us to generate Change log. The Angular specification is recommended.

The installation

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

configuration

// .huskyrc
{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged",
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  }
}
Copy the code
// commitlint.config.js
module.exports = {
  extends: ['@commitlint/config-conventional']}Copy the code

When our Commit message does not conform to the specification, we cannot commit ❌

Let’s modify the Commit Message to conform to the Angular specification and commit ✅ again

usecommitizenWrite a commit Message that complies with the specification

The installation

#Global installation
npm install -g commitizen

#Project-level installation
npm install -D commitizen cz-conventional-changelog
Copy the code

configuration

For a global installation, run the following command in the project directory to support Angular’s Commit Message format.

commitizen init cz-conventional-changelog --save --save-exact
Copy the code

For a project-level installation, add the following configuration to package.json:

{
  "script": {
    "...": "..."."commit": "git-cz"
  },
  "config": {
    "commitizen": {
      "path": "node_modules/cz-conventional-changelog"}},"...": "..."
}
Copy the code

Now, use git Cz (for global installations) or NPM run commit (for project-level installations) instead where you need to use git commit. Then generate the canonical COMMIT message on the command line by answering questions. Translation:

  1. Research the type of change that you’re committing (Use arrow keys) (up and down arrow keys)

    • Feat: A new feature feat
    • -Dan: I’m fixing A bug
    • Docs: Documentation only changes docs: Modifies documents in the project
    • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc) style: Changes that do not affect code logic (whitespace, formatting, missing semicolons, etc.)
    • Refactor: A code change that neither fixes A bug nor adds A feature refactor: A code change that neither fixes A bug nor adds A feature
    • Perf: A code change that improves performance PerF: Performance optimization
    • Test: Adding missing tests or correcting existing tests test: testing code changes
    • build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) build: Build tool or external dependency changes
    • ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) ci: Modify CI configuration files and script files
    • Chore: Other changes that don’t modify SRC or test files chore: Other changes that don’t modify SRC or test files
    • Reverts a previous commit Reverts Reverts a previous commit

  2. What is the scope of this change (e.g. component or file name): (press enter to skip)

  3. Write a short, imperative tense description of the change (Max 95 Chars)

  4. Provide a longer description of the change: (Press enter to skip)

  5. Are there any breaking changes? (Y /N) Are there any changes incompatible with the previous version?

  6. Does this change affect any open issues? (Y /N) Does the submission address certain issues?

useconventional-changelogGenerate the Change log

If our Commit Messages all conform to the specification above, then the Change log document will be generated automatically when the project is published.

The installation

npm install -D conventional-changelog-cli
Copy the code

configuration

// package.json { "scripts": { "..." : "..." "Changelog ":" Conventional - Changelog -p angular-i./ Your custom path/changelog.md-s-r 0"}, "..." : "..." }Copy the code

Run NPM run change log to generate the Changelog. md file.