当前位置：首页 > news >正文

江苏做家纺的公司网站北京关键词快速排名

news 2026/4/7 8:00:24

江苏做家纺的公司网站,北京关键词快速排名,全网营销推广哪家正规,如何经营电商平台前言通常情况下，一个 git 仓库就是一个项目，只需要配置一套 git hooks 脚本就可以执行各种校验任务。对于 monorepo 项目也是如此，monorepo 项目下的多个 packages 之间，它们是有关联的，可以互相引用，所以…

前言

通常情况下，一个 git 仓库就是一个项目，只需要配置一套 git hooks 脚本就可以执行各种校验任务。对于 monorepo 项目也是如此，monorepo 项目下的多个 packages 之间，它们是有关联的，可以互相引用，所以当成一个项目也没问题。

但是也有一种情况，一个 git 仓库下的多个项目之间是彼此独立的，比如 git 仓库下存在前端项目、后端项目、文档项目等等。这时候就需要为每个项目配置不同的 git hooks 脚本了，因为不同的项目有可能校验规则不一样。

本文主要探讨一下如何为不同的项目配置 git hooks 脚本。

PS：配置 git hooks 脚本使用 huksy。

方案一：每个项目下都配置一套 git hooks 脚本

假设仓库拥前后端两个项目：

frontend
backend

那么我们需要在每个项目下安装 husky，同时要在 package.json 中配置一下 prepare 脚本（这里以前端项目为示例）：

# package.json
{"scripts" {"prepare": "cd .. && husky install frontend/.husky"}
}

然后按照 husky 文档创建 pre-commit 和 commit-msg 钩子文件：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"# pre-commit
cd frontend
npx lint-staged

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"# commit-msg
cd frontend
FORCE_COLOR=1 node scripts/verifyCommitMsg.mjs $1

上面展示的是前端项目的 git hooks 创建过程，后端项目按照同样的过程创建即可。目前仓库的目录结构如下：

frontend.husky- pre-commit- commit-msg
backend.husky- pre-commit- commit-msg

运行一段时间后，发现这个方案有问题，那就是每次触发的 git hooks 脚本都是前端项目的，后端项目提交代码根本不触发 git hooks。排查问题后发现是 git 仓库的配置引起的，打开 .git/config 文件：

[core]hooksPath = frontend/.husky

上面 hooksPath 路径对应的就是 git hooks 的目录位置，目前 git 只支持指定一个目录作为 git hooks 的位置。所以第一个方案不靠谱，达不到我们想要的效果。

方案二：只在根目录下配置一套 git hooks 脚本

第二个方案是将 git hooks 放在项目根目录下，统一在根目录里执行各个子项目的校验脚本。这个方案有以下几个步骤：

修改 husky 安装位置

在每个项目下安装 husky 时，要把 git hooks 钩子目录设置在根目录：

# package.json
{"scripts" {"prepare": "cd .. && husky install .husky" # 放到根目录}
}

同时 .git/config 文件也要修改一下：

[core]hooksPath = .husky # 改为根目录

在 git hooks 中进行各个子项目的校验操作

这里以 commit-msg 作为示例编写一个脚本：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"# 拿到所有改动的文件名
changedFiles=$(git diff --cached --name-only --diff-filter=ACM)# 判断目录是否改动
isBackendChanged=false
isFrontendChanged=falsefor file in $changedFiles
doif [[ $file == frontend/* ]]thenisFrontendChanged=trueelif [[ $file == backend/* ]]thenisBackendChanged=truefi
done# 改动的目录需要执行校验命令
# $1 $2 代表传给函数的第一个、第二个参数
execTask() {echo "root $1 commit-msg"cd $1FORCE_COLOR=1 node scripts/verifyCommitMsg.mjs $2
}if $isFrontendChanged
thenexecTask "frontend" $1 & # 使用 & 让任务在后台执行task1=$! # 保存任务 id
fiif $isBackendChanged
thenexecTask "backend" $1 &task2=$!
fiif [[ -n $task1 ]]; thenwait $task1
fiif [[ -n $task2 ]]; thenwait $task2
fiecho "All tasks finished."

上面脚本的逻辑是这样的：

每次 git 提交代码时，判断一下当前所有改动的文件是属于哪个项目
文件发生改动的项目需要执行校验任务
每个校验任务都使用子进程去执行
等待所有校验任务执行结束后，输出 All tasks finished.

`pre-push` 脚本编写

与 pre-commit 和 commit-msg 不同，在 pre-push 钩子中需要通过其他方式来拿到发生改动的文件，大家直接看代码：

#!/usr/bin/env sh
. "$(dirname -- "$0")/_/husky.sh"# 判断目录是否改动
isFrontendChanged=false
isComponentTemplateChanged=false
isComponentAttrPanelChanged=false# 获取远程仓库的名字和 URL
remote="$1"
url="$2"# 定义一个空的 git 哈希值
z40=0000000000000000000000000000000000000000# 这个循环从 stdin 读取数据，这些数据是 git 在调用 pre-push 钩子时传递的。
# 每一行数据包括 4 个字段：本地引用名，本地最新的提交哈希值，远程引用名，远程最新的提交哈希值。
while read local_ref local_sha remote_ref remote_sha
do# 这段代码检查是否正在删除一个引用（例如，删除一个分支）。如果是，那么本地的 sha 值将被设置为一个空哈希值。if [ "$local_sha" = $z40 ] then# Handle delete:else# 这段代码确定要检查哪些提交。如果远程的 sha 值是一个空哈希值，那么我们正在创建一个新的引用，所以我们需要检查所有的提交。# 否则，我们正在更新一个已经存在的引用，所以我们只需要检查新的提交。if [ "$remote_sha" = $z40 ] then# New branch, examine all commitsrange="$local_sha"else# Update to existing branch, examine new commitsrange="$remote_sha..$local_sha"fi# 这个循环对每一个包含在 range 变量中的提交执行 git rev-list 命令，这个命令会返回一系列的提交哈希值。# 然后，对每个提交，我们使用 git diff-tree 命令来找到在那个提交中修改的文件。这些文件的名字被存储在 files 变量中。for commit in $(git rev-list "$range"); do# 拿到所有改动的文件名files=$(git diff-tree --no-commit-id --name-only -r $commit)for file in $filesdoif [[ $file == frontend/* ]]thenisFrontendChanged=trueelif [[ $file == component-attr-panel/* ]]thenisComponentAttrPanelChanged=trueelif [[ $file == component-template/* ]]thenisComponentTemplateChanged=truefidonedonefi
done# 改动的目录需要执行校验命令
execTask() {echo "root $1 pre-push"cd $1npm run type-check
}if $isFrontendChanged
thenexecTask "frontend" & # 使用 & 让任务在后台执行task1=$! # 保存任务 id
fiif $isComponentTemplateChanged
thenexecTask "component-template" &task2=$!
fiif $isComponentAttrPanelChanged
thenexecTask "component-attr-panel" &task3=$!
fiif [[ -n $task1 ]]; thenwait $task1
fiif [[ -n $task2 ]]; thenwait $task2
fiif [[ -n $task3 ]]; thenwait $task3
fiecho "All tasks finished."