git commit前检测husky与pre-commit 提交钩子

git commit前检测husky与pre-commit

git commit前检测husky与pre-commit - 简书 https://www.jianshu.com/p/f0d31f92bfab

Prettier · Opinionated Code Formatter https://prettier.io/
{ "husky": { "hooks": { "pre-commit": "pretty-quick --staged" } } }

a@test MINGW64 /d/code/app_wxa (v3.0)

$ ll -as

total 295

  4 drwxr-xr-x 1 Administrator 197121      0 七月 12 22:55 ./

  4 drwxr-xr-x 1 Administrator 197121      0 五月  9 11:53 ../

  4 drwxr-xr-x 1 Administrator 197121      0 七月 12 22:57 .git/

  1 -rw-r--r-- 1 Administrator 197121     32 四月  3 21:29 .gitignore

  1 -rw-r--r-- 1 Administrator 197121    412 四月 26 17:46 .prettierrc

  0 drwxr-xr-x 1 Administrator 197121      0 七月 12 22:55 node_modules/

  0 drwxr-xr-x 1 Administrator 197121      0 七月 12 22:57 app/

  4 -rw-r--r-- 1 Administrator 197121    856 七月 12 22:44 package.json

276 -rw-r--r-- 1 Administrator 197121 278578 七月 12 22:55 package-lock.json

 

a@test MINGW64 /d/code/app_wxa (v3.0)

$ cat .prettierrc

{

    printWidth: 180,

    semi: true,

    tabWidth: 4,

    useTabs: false,

    singleQuote: true,

    trailingComma: "none",

    bracketSpacing: true,

    htmlWhitespaceSensitivity: "ignore",

    parsers: {

        ".jsx": "flow",

        ".scss": "scss",

        ".ts": "typescript",

        ".less": "css",

        ".vue": "vue",

        ".nvue": "vue",

        ".ux": "vue",

        ".yml": "yaml",

    }

}

 

 

a@test MINGW64 /d/code/app_wxa (v3.0)

$ cat package.json

{

    "husky": {

        "hooks": {

            "pre-commit": "pretty-quick --staged"

        }

    },

    "devDependencies": {

        "husky": "^4.2.3",

        "lint-staged": "^10.1.1",

        "prettier": "2.0.2",

        "pretty-quick": "^2.0.1"

    },

    "dependencies": {

        "@babel/core": "^7.9.0",

        "chalk": "^3.0.0",

        "eslint": "^6.8.0",

        "execa": "^4.0.0",

        "find-up": "^4.1.0",

        "ignore": "^5.1.4",

        "jquery": "^3.4.1",

        "miniprogram-sm-crypto": "^0.1.0",

        "mri": "^1.1.5",

        "multimatch": "^4.0.0",

        "node-rsa": "^1.0.8",

        "npx": "^10.2.2",

        "prettier": "^2.0.2",

        "pretty-quick": "^2.0.1",

        "trim": "0.0.1",

        "vue": "^2.6.11",

        "yaml": "^1.8.3"

    },

    "lint-staged": {

        "*.{js,css,md}": "prettier --write"

    }

}

 

 

git commit前检测husky与pre-commit - 简书 https://www.jianshu.com/p/f0d31f92bfab

prevent commit时，我们可以把eslint以及test命令加上，检测代码规范：

"scripts": {

    "precommit": "lint-staged && npm run test"

https://www.npmjs.com/package/pre-commit https://www.npmjs.com/package/pre-commit

 

 

git commit触发的hook - 简书 https://www.jianshu.com/p/b532d62da0f1

git中提供了一组hook，规定了每个hook的名字，以及hook接收的参数个数和每个参数的含义。用户如果要使用hook的话，需要在.git/hooks/目录中创建对应名字的hook文件，赋予该文件可执行权限，用bash或者python或者其它脚本语言来实现该hook具体要做哪些事。hook就是类似于onClick()、onRun()这样的事件，也可以理解成是一组回调函数。

git commit是最常用的命令之一，它可以触发四个hook，分别是pre-commit，prepare-commit-msg，commit-msg和post-commit。从字面上可以猜测到这四个hook分别对应“commit之前”、“准备commit log message的时候”、“生成commit log message的时候”、“commit之后”这四个触发时机。这四个hook也的确是按照这个先后顺序被触发的。如果git commit时使用了-n（等价于--no-verify）参数的话，pre-commit和commit-msg就不会被触发。

pre-commit不接收参数。这个hook可以用来在commit之前检查修改的代码是否符合规范、检查文件名是否含有空格、或者仅仅单纯地输出“hello world”等等，具体想要做什么可以根据实际情况来决定。如果以非0状态退出的话，譬如检测到文件名中有空格，而用户不希望这种文件被commit，在这种情况下执行exit 1，那么git commit会以失败而终止。

prepare-commit-msg接收三个参数。第一个是commit log message所在的文件名，通常是.git/COMMIT_EDITMSG。第二个是commit log message的来源。在《git commit中输入message的几种方式》 中有介绍过-m，不加参数，-c，-C，-F，-t等方式输入commit log message，这些都是不同的来源。如果是-m的话，第二个参数的值是"message"；如果是不加参数的话，第二个参数的值是""；如果是-c或-C或者其他情况但加了--amend参数的话，第二个参数的值是"commit"；如果是-F的话，第二个参数的值是"message"；如果是-t或者设置了commit.template的话，第二个参数的值是"template"。

如果第二个参数不是"commit"，那第三个参数值为""。如果第二个参数值是“commit"的话，那第三个参数值就是-c或者-C后面接的那个值，可能是tag name、branch name、HEAD、HEAD^1、具体的某个commit SHA-1等等。有--amend的话，第三个参数值是"HEAD"。

此外，git merge和git cherry-pick可能会触发这个hook。git merge如果是ff(fast-forward) merge那不会触发这个hook，但如果发生no-ff类型的merge，或者git merge --no-ff，那么会触发这个hook，第二个参数值为"merge"；git merge --squash && git commit的情况下，第二个参数值为"squash"。git cherry-pick默认情况下会触发这个hook，除非使用了-n（等价于--no-commit）参数，第二个参数值为"message"。

理论上来说，pre-commit中的事情可以放到prepare-commit-msg中来做，但不推荐这么做 。prepare-commit-msg的设计本意是在commit-msg之前编辑message文件用的。譬如，希望在commit log message中记录下当前某个系统的某些状态值（譬如jenkins上某个编译job的环境变量和用户变量），那可以在prepare-commit-msg中对准备用于-F或者-t的文件进行编辑，将那些实时获取的状态值插入到文件中去。然后这个文件的内容会被写入.git/COMMIT_EDITMSG，commit成功以后，这些内容就变成了commit log message的一部分。当然，这些内容也可以在git commit之前组织好，然后在git commit的时候直接用起来。但如果放在hook里来做，就等于封装到了git commit的内部。用户可以根据实际情况考量是否需要用这个hook。同样的，这个hook如果以非0状态退出的话，会使git commit失败而终止。

和prepare-commit-msg比起来，commit-msg使用的场景更多些。这个hook接收一个参数，commit log message所在的文件名，通常是.git/COMMIT_EDITMSG。从这个文件中，可以读取到最终运用于commit log message的内容。比较常见的运用是在这里检查commit log message是否符合事先规定的格式。另外一个实际运用是使用gerrit系统的场合下，git commit时会根据已有的信息生成一个类似commit SHA-1的Change-Id，并将其插入到commit log message中去。生成Change-Id的算法会用到用户编辑完成后的commit log message的内容，所以生成Change-Id的动作不能在commit-msg之前做。同样的，这个hook如果以非0状态退出的话，会使git commit失败而终止。

post-commit在commit完成后被触发，不接收参数。post-commit能够执行，说明git commit已经成功了。接下来可以做很多事，譬如执行git push到一个备份branch上，或者启动编译，或者关机（每天只做一个commit），或者也可以很无聊地git reset --hard回到新生成的commit的parent上（这么做毫无意义），也可以把硬盘格式化掉（再见！）

要试验这四个hook的话，可以在.git/hooks/下创建四个文件，文件名分别为pre-commit，prepare-commit-msg，commit-msg，post-commit，将它们都改为可执行文件。假如要用hook打印每个hook接收了哪些参数：

#！/usr/bash

echo $@

或者

#!/usr/bin/env python

import sys

print sys.argv

然后执行各种git commit看看效果吧。别忘了每个hook的参数列表第0个是hook文件的路径，后面才是接收的参数。hook是一扇门，你的脑洞有多大，门后面的世界就有多大。

 

 

Git - Git Hooks https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks

 

 git hook实现代码自动部署_君君的专栏-CSDN博客_git hook https://blog.csdn.net/u010837612/article/details/70825225

1. git用户执行git push操作
2. 远程仓库发现有用户执行了push操作，就会执行一个脚本post-receive（钩子）
3. 在post-receive脚本中，将git仓库的代码拷贝到web站点目录下