This article has participated in the good article call order activity, click to see: back end, big front end double track submission, 20,000 yuan prize pool for you to challenge!

Hello, everyone. I’m Han, a front-end engineer who is constantly learning and constantly writing bugs

Writing in the front

On a daily basis, almost every project is maintained by more than one person, each of whom has different writing habits and styles. If you don’t have a common specification, you’ll find a lot of different types of code to commit to the repository and a lot of commit logs. Commit message: Commit message: Commit message: commit message: commit message: commit message: commit message The end result is that when you need to cherry-pick a commit to another branch one day, you look at the Commmit log in a muddleheaded way. Therefore, norms and constraints are particularly important when multiple people work together.

githooks

Similar to the lifecycle hooks in the front-end framework, Git has hooks that perform certain functions before or after certain events. Githooks are scripts that are triggered when Git performs certain events (such as commit, push, receive, etc.).

The githooks are saved in the.git folder

The specific hooks are shown in the following table:

git hook Execution time instructions
applypatch-msg Git AM before execution By default, the applpatch-msg hook runs the commit-msg hook when it is enabled if commit-msg is enabled
pre-applypatc Git AM before execution The default pre-Applypatch hook runs the pre-Commit hook when enabled (if enabled)
post-applypatch After git AM is executed This hook is primarily for notification and does not affect the results of Git-AM
pre-commit Git commit before execution You can bypass this hook by using the git commit –no verify command
pre-merge-commit Before git merge You can bypass this hook by using the git merge –no verify command
prepare-commit-msg After git commit is executed, but before the editor opens
commit-msg Git commit before execution You can bypass this hook by using the git commit –no verify command
post-commit After git commit is executed Does not affect the result of git commit
pre-rebase Git rebase before execution
post-checkout After git checkout or Git switch is executed If the –no-checkout parameter is not used, it will also be executed after Git Clone
post-merge After the Git merge is executed It is also called when a Git pull is performed
pre-push Git push before execution
pre-receive Before git Receive Pack is executed
update
proc-receive
post-receive Before git Receive Pack is executed The execution result of Git Receive Pack is not affected
post-update When the Git Receive Pack responds to Git Push and updates references in the repository
reference-transaction
push-to-checkout When git the receive pack react to git push and update the reference in the warehouse, and when trying to update the current be. Check out the branch and the receive is updateInstead denyCurrentBranch configuration
pre-auto-gc Git gc –auto Before execution
post-rewrite Git commit –amend or Git rebase
sendemail-validate Git send-email Before execution
fsmonitor-watchman Git /hooks/fsmonitor-watchman or. Git /hooks/fsmonitor-watchmanv2
p4-changelist Git-p4 submit after executing and editing the Changelist message You can bypass this hook by using git-p4 submit –no-verify
p4-prepare-changelist After git-p4 submit executes, the editor starts before You can bypass this hook by using git-p4 submit –no-verify
p4-post-changelist After git-p4 submit is executed
p4-pre-submit Git-p4 submit before execution You can bypass this hook by using git-p4 submit –no-verify
post-index-change The index was written to read-cache.c do_write_locked_index

Husky (v7.0.1)

Husky is a tool that makes it easier to configure Git hooks. Support for all Git hooks.

Use husky

  • First run the installation commandnpm install husky --save-dev
  • To automatically enable hooks after installation, we need to executenpm set-script prepare "husky install"
  • After executing the previous command, you can see the following code in the scripts configuration item of the package.json file:
"scripts": {
    "prepare": "husky install"
}
Copy the code

  • Yarn husky add.husky /commit-msg ‘yarn commitlint –edit “$1″‘

  • Add the commit-msg hook you created in the previous step to git: git add.husky /commit-msg

  • There is also the husky-init command, which can be executed to quickly initialize a husky in a project.

Lint – staged (v11.0.0)

Lint-passage is a tool that runs Linters on the Git staging area. (Run linters against staged git files and don’t let 💩 slip into your code base!)

It will install and configure Husky and Lint-Staged according to the code quality tools in the package-json dependency, so make sure to install (NPM install –save-dev) and configure all code quality tools, such as Prettier and ESlint, before then.

  • Install: Executeyarn add lint-staged -DThe command
"Lint-passage" --help command: lint-passage [options]Options: -v, --version Output version number --allow-empty Allows empty commits when the task undoes all phased changes (default:false) -c, --config [path] Specifies the path to the configuration file -d, --debug Displays other debugging information (default:false) -p, --concurrent <parallel Tasks > Number of tasks to be run simultaneously, orfalseTo run the task continuously (default:true-q, --quiet your own console output (default:false) -r, --relative passes relative file paths to the task (default:false) -x, -- Shell skips task resolution to better support the shell (default:false) -h, --help Displays usage informationCopy the code
  • –allow-empty: Use this parameter to allow the creation of empty Git commits. By default, when the LITER task undoes all the periodic changes, the LITET phase throws an error and aborts the commit.

Git Commit specification

Usually use the requirements of the Google AnguarJS specification. Format requirements:

<type>(<scope>) :<subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
Copy the code
  • <type>The type of the commit, such as fixing a bug or adding a feature, is:
type describe
feat The new feature
fix Fix the bug
docs Only the document is modified, such as README, CHANGELOG, CONTRIBUTE, etc.
style Only whitespace, indentation, commas, etc. are changed without changing the code logic.
refactor Code refactoring, no new features or bug fixes
perf Optimizations related, such as improved performance, experience
test Test cases, including unit tests, integration tests, etc
chore Change the build process, or add dependencies, tools, etc
revert Roll back to the previous version
  • scope: Indicates the scope of the impact of the COMMIT. Scope is project-specific; for example, it can be divided by menu or functional module in a business project, or by component in the case of component library development.
  • subject: is a short description of commit;
  • body: Submit a detailed description of the code;
  • footerFooter must be required if the code is submitted as an incompatible change or close defect, otherwise it can be omitted.

implementation

  • To install the dependencies we need, run the following command:

  • Run yarn add husky -d to install husky.

  • After executing NPM set-script prepare” husky install”, you can see “prepare”: “husky install” in the scripts configuration item of the package.json file.

Ps: After the yarn set-script prepare “husky install” Command is executed, error Command “set-script” is not found.

  • Continue to performyarn prepareAfter that, you can see the following directories in the project root directory:

  • If you executeyarn prepareIf an error is reported as shown in the following figure, you need to executegit initAnd then executeyarn prepare

  • With Husky ready, let’s go ahead and install the other used specifications and check for code dependencies.

  • Run yarn add lint-passage -d

  • The yarn add eslint prettier -d command is used

  • Add the following code under the package.json file:

"lint-staged": {
    "src/**/*.{js,jsx,ts,tsx,json}": [
      "prettier --write"."eslint"."git add"]}Copy the code

  • Run the yarn add@commitlint/cli@commitlint /config-conventional -d command to install commitlint-related dependencies to help comply with git commit conventions during multi-party development.

  • Echo “module.exports = {extends: [‘ @commitlint.config.js ‘]}” > commitlint.config.js (commitlint.config.js) [‘ @commitlint.config.js ‘]}” > commitlint.js (commitlint.config.js)

module.exports = {
  extends: [
    "@commitlint/config-conventional"].// The following is our custom rule
  rules: {
    'type-enum': [
      2.'always'['bug'.// This is specific to the bug number. It is used to report back to the test the bugs in the bug list
        'feat'.// New feature (feature)
        'fix'./ / repair the bug
        'docs'.// Documentation
        'style'.// Format (changes that do not affect code running)
        'refactor'.// Refactoring (i.e., code changes that are not new functionality or bug fixes)
        'test'.// Add tests
        'chore'.// Changes to the build process or auxiliary tools
        'revert'.// feat(pencil): add 'graphiteWidth' option
        'merge' // Merge the branch, for example: merge (front page) : feature-xxxx modifs the thread address]]}};Copy the code

  • If you need additional code optimization dependencies, you can install them

  • At this point, with the dependencies we need ready, we start adding hooks

  • Yarn husky add. husky/commit-msg ‘yarn commitlint –edit “$1″‘

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

yarn commitlint --edit "$1"
Copy the code

  • Next, we need to add the hooks we added in the previous step to Git by executing git add.husky /commit-msg

  • Yarn husky add. husky/pre-commit ‘yarn lint-staged –allow-empty “$1″‘ will look like this:

#!/bin/sh
. "$(dirname "$0")/_/husky.sh"

yarn lint-staged --allow-empty "$1"
Copy the code

  • Again, we need to add the hooks we added in the previous step to Git by executing git add.husky /pre-commit

  • Next, it’s time to verify our configuration: When we commit correctly according to the COMMIT specification, we can see the following output in the console

  • When we commit without following the configured specifications, we find the following error and prevent you from committing code

  • At this point, our hook configuration has been perfect!

Write in the last

Writing is not easy, welcome to click (1) like (key) collect (3) hide (even), if there is a mistake, welcome to comment and correct!!

I’m Han, a front-end engineer who’s constantly learning, constantly writing bugs. Pay attention to me, don’t get lost. Study together and make progress together.