This paper mainly solves the following problems:

  1. What are Git Hooks?
  2. How to make it easier to share git Hooks with others?

The github repository for this article is github.com/eyunhua/cod…

preface

In our daily development process, git (distributed version control tool) is often used to manage our projects, so that multiple people can work together anytime, anywhere. Git commit -m ‘XXX’ after you have developed a function, you need to commit code to the code base with git commit -m ‘XXX’ command. This involves checking the submitted code and message for compliance with the defined specifications.

This article will focus on the gitHooks hook function and use, combined with the code submission inspection, using tools to generate message, automatic generation of changelog this article, to make our code submission process more standardized!

Git hooks hooks

What are Git hooks

Git hooks are custom scripts that control the flow of Git work. They are divided into client-side hooks and server-side hooks.

Client-side hook

There are many types of client hooks. They are divided into submit workflow hooks, E-mail workflow hooks, and others. This section describes how to submit workflow hooks: pre-commit, prepare-commit-msg, commit-msg, and post-commit.

Pre-commit (Common)

Run before you type the submission information. It is used to check the snapshot that is about to be committed. For example, check for omissions, make sure tests run, and check code. If the hook exits with a non-zero value, Git will abandon the commit, but you can bypass this by using Git commit –no-verify. You can use this hook to check if the code style is consistent (running lint-like programs), if trailing whitespace exists (the built-in hooks do this), or if the new method is properly documented.

prepare-commit-msg

Run after the default information is created before starting the Submit information editor. It allows you to edit the default information that submitters see. The hook receives options: the path of the file that holds the current commit information, the commit type, and the SHA-1 validation of the commit that fixes the commit. It is not useful for general submissions; However, it is useful for commits that automatically generate default information, such as commit information templates, merge commit, compress commit, and revise commit. You can use it in conjunction with the submission template to dynamically insert information.

Commit – MSG (common)

Receives a parameter, the path to the temporary file mentioned above that holds the current commit information. If this hook script exits with a non-zero value, Git will abandon the commit, so it can be used to verify project status or commit information before the commit passes.

post-commit

Run after the entire commit process is complete. It doesn’t take any arguments, but you can easily get the last commit information by running Git log-1 HEAD. This hook is usually used for things like notifications.

Server-side hook

In addition to client-side hooks, as a system administrator, you can use several server-side hooks to enforce various types of policies on projects. These hook scripts run before and after they are pushed to the server. A hook that runs before a push to the server can exit at any time with a non-zero value, reject the push and return an error message to the client, and you can set up a push strategy as complex as you want. Hooks include pre-receive, Update, and post-receive.

pre-receive

When handling push operations from clients, the first script invoked is pre-receive. It takes a set of pushed references from standard input. If it exits with a non-zero value, none of the tweets will be accepted. You can use this hook to block non-fast-forward updates to references or to control access to all references and files that the push changes.

update

The Update script is very similar to the pre-receive script, except that it runs once for each branch that is ready to be updated. Pre-receive only runs once if a pusher pushes content to multiple branches at the same time, whereas Update runs once for each branch that is pushed. Instead of reading content from standard input, it takes three parameters: the name of the reference (branch), the SHA-1 value of the content that the reference points to before the push, and the SHA-1 value of the content that the user is about to push. If the update script exits with a non-zero value, only the corresponding reference will be rejected; The rest will still be updated.

post-receive

The post-receive hook is run at the end of the process and can be used to update other system services or notify users. It accepts the same standard input data as pre-receive. Its uses include sending a message to a mailing list to notify the continous Integration server, Or update ticket-tracking systems — or even analyze submitted information to determine whether a ticket should be turned on, changed, or closed. The script cannot terminate the push process, but the client will remain connected until it finishes running, so use it with caution if you want to do anything else, as it will take you a long time.

Git hooks to install

When you initialize a new repository with git init, git places sample scripts in this directory by default. Go to.git/hooks and you will see official examples of hooks with file names ending in.sample.

Git hooks store location

Git hooks are stored in the.hooks subdirectory of the git directory, that is, in most projects.

Git hooks sample

In addition to being called themselves, the sample scripts in the.git/hooks directory reveal the parameters passed when triggered. All of the examples are shell scripts, and some of them are mixed in with Perl code, but any properly named executable script will work fine — you can write them in Ruby or Python, or any language you’re familiar with.

git initA sample script is generated, as shown in the following figure

Call the git hooks

Note that these sample scripts ending with.sample do not execute by default, and will only be activated, effective, and invoked by Git if a properly named (without the.sample extension) executable file is placed in the.git/hooks directory.

Bug with local.git/hooks

Because the.git folder is not tracked by Git, hooks in the.git/hooks directory cannot be committed and therefore cannot be shared with others.

If we use Git hooks, we need to share the hooks within the code base. For this problem, let’s look at two easy ways to specify Git Hooks.

husky

introduce

Husky can expose git’s built-in hooks for easy hook injection without having to write shell scripts in the.git/hooks directory. You can use it to lint your commit messages, run tests, lint code, and more. When you commit or push. Husky triggers all Git hook scripts.

Install

Automatic Installation (recommended)

The husky init command will use husky to quickly initialize the project.

npx husky-init && npm install
Copy the code

Manual installation

  1. install husky
npm install husky --save-dev
Copy the code
  1. To enable thehusky
npx husky install
Copy the code
  1. To automatically enable Git hooks after installation, editpackage.json
npm set-script prepare "husky install"
Copy the code

After the preceding installation commands are executed, the following changes occur:

  1. in.gitPeer directory generation.huskyFolder, which has an example that can be editedpre-commithook
  2. inpackage.jsonIn thescriptsAdd the"prepare": "husky install"
  3. To change thegitConfiguration itemscore.hooksPathfor.husky

The diagram below:

Create a Hook

To add another hook, use husky Add.

Example:

npx husky add .husky/commit-msg 'npx --no-install commitlint --edit "$1"'
Copy the code

Update hooks script

Change the hooks script in the. Husky folder.

The diagram below:

Call hooks

A hook added by Husky is automatically called when you run git commit.

Uninstall and restore Husky

npm uninstall husky
// Delete the.husky folder and reset core.hookspath
rm -rf .husky && git config --unset core.hooksPath
Copy the code

yorkie

introduce

Fork made some changes from Husky as follows:

  1. Give priority to.gitNext to the catalogpackage.json“Rather than hard-coded upward search. To avoid the inlernaBoth root packages and subpackages in the repository depend onhusky“, which would confuse and double update the root with the wrong pathgitHook.
  2. Changes in thepackage.jsonIn thehooksThe location of the

Before:

{
  "scripts": {
    "precommit": "foo"}}Copy the code

After:

{
  "gitHooks": {
    "pre-commit": "foo"}}Copy the code

Install

Vue -cli After initializing the project, @vue/cli-service automatically installs Yorkie, which lets you easily specify Git hooks in the Package. json gitHooks field:

{
  "gitHooks": {
    "pre-commit": "lint-staged" // Configure the script
  },
   "lint-staged": {
    "*.{js,vue}": [
      "vue-cli-service lint"."git add"]}}Copy the code

Pay attention to

Yorkie forks from husky and is incompatible with the latter.

Husky is different from Yorkie

  • huskyV7 only supports modification.husky/xxxConfiguration scripts in the directory, supported by VERSION V4package.jsonThrough thehusky: {hooks: {"pre-commit": xxx} }To update the script
  • yorkieSupport inpackage.jsonThrough the"gitHooks": {"pre-commit": xxx}To update the script.

Skip the hooks

Sometimes we want to bypass the hooks check for a number of reasons by using the following command:

git commit -m 'xxx' --no-verify
Copy the code

Next:Juejin. Cn/post / 697689…, describes how to check the code, generate a COMMIT message, and generate changelog to make the whole project submission process more standardized.