Linux Git Hooks 自动校验 CSS 提交前格式化实践

什么是 Git Hooks？

Git Hooks 是 Git 提供的一种机制，允许在特定的 Git 操作（如提交、推送、合并等）前后自动执行自定义脚本。这些脚本通常存放在项目根目录下的 .git/hooks 文件夹中。虽然默认情况下这些钩子是独立于版本控制之外的，但通过一些工具（如 Husky 或自定义安装脚本），我们可以将其集成进项目流程，实现团队协作的一致性。

在前端开发中，代码风格统一至关重要，尤其是像 CSS 这类对空格、缩进、命名规则敏感的语言。一个未格式化的样式文件不仅影响可读性，还可能引发团队成员之间的“空格战争”。因此，在代码提交前自动检测并阻止未格式化 CSS 的行为，是一种高效且必要的工程实践。

为什么要在提交前校验 CSS 格式？

想象这样一个场景：你正在审查同事的 Pull Request，发现其中一段 CSS 写得错落有致——属性顺序混乱、缩进不一致、缺少分号。你提出修改建议，对方回复：“我本地用的是 Prettier，应该没问题啊。” 结果一查，原来他忘了保存时自动格式化，或者编辑器配置出错了。

这类问题在多人协作中屡见不鲜。而 Git Hooks 正是用来解决这种“人为疏忽”的利器。它能在 git commit 执行时触发检查，若发现未格式化的 CSS 文件，立即中断提交流程，并提示开发者运行格式化命令。这不仅提升了代码质量，也减少了 Code Review 中关于格式的无效争论。

更重要的是，这种机制把规范变成了强制流程，而不是依赖文档或口头约定。新人加入项目后，只要克隆代码并完成初始化，就能自动受到约束，无需额外培训。

如何使用 Git Hooks 实现 CSS 格式校验？

实现这一功能的核心在于 pre-commit 钩子。该钩子在每次提交前运行，适合用来做静态检查和格式验证。

首先，在项目中引入代码格式化工具。目前主流选择是 Prettier，它支持 CSS、SCSS、Less 等多种样式语言。安装方式如下：

bash npm install --save-dev prettier

接着，在项目根目录创建 .prettierrc 配置文件，明确格式规则：

json { "semi": true, "trailingComma": "es5", "singleQuote": true, "printWidth": 80, "tabWidth": 2, "useTabs": false, "endOfLine": "lf" }

然后，我们需要编写一个 pre-commit 脚本。进入 .git/hooks/ 目录（注意：这是本地仓库的隐藏目录），创建名为 pre-commit 的可执行文件：

bash

!/bin/bash

echo "🔍 正在检查 CSS 文件格式..."

查找所有暂存区中的 CSS 文件

CSS_FILES=$(git diff --cached --name-only --diff-filter=ACM | grep '.css$')

if [ -z "$CSS_FILES" ]; then
echo "✅ 无待提交的 CSS 文件，跳过格式检查。"
exit 0
fi

临时保存原始暂存内容

git stash push -q --keep-index

对每个 CSS 文件运行 Prettier 检查

HAS_UNFORMATTED=false

for file in $CSSFILES; do if ! npx prettier --check "$file" > /dev/null 2>&1; then echo "❌ $file 未正确格式化，请运行 'npx prettier --write $file' 修复" HASUNFORMATTED=true
fi
done

恢复暂存区

git stash pop -q > /dev/null 2>&1

if [ "$HAS_UNFORMATTED" = true ]; then
echo "⚠️ 存在未格式化的 CSS 文件，提交已被阻止。"
exit 1
fi

echo "✅ 所有 CSS 文件格式正确，允许提交。"
exit 0

别忘了给这个脚本添加执行权限：

bash chmod +x .git/hooks/pre-commit

这样，每当有人尝试提交 CSS 文件时，系统都会自动校验其格式是否符合 Prettier 规范。如果有文件不符合，提交将被拒绝，并给出具体修复指令。

团队协作中的注意事项

尽管上述方案在技术上完全可行，但在实际落地时仍需考虑团队接受度。直接强制拦截提交可能会引起抵触情绪，特别是对于不熟悉命令行操作的成员。

建议采取渐进式策略：初期将 pre-commit 设置为仅警告模式，即打印提示但不阻止提交；待团队适应后再开启严格模式。也可以结合 CI/CD 流程，在流水线中添加格式检查步骤，作为本地钩子的补充。

此外，.git/hooks 目录本身不会被 Git 跟踪，这意味着每个开发者都需要手动设置钩子。为解决这个问题，可以使用 Husky 这样的工具，它能通过 npm script 自动管理 Git Hooks 的安装与同步，确保所有协作者使用相同的钩子逻辑。

总结与延伸思考

更重要的是，这种自动化机制传递了一种工程文化：质量不是靠人盯出来的，而是靠系统保障的。当每一个微小的提交都经过层层校验，最终汇聚成的代码库自然更加健壮、可维护。

真正的高效开发，不在于写得多快，而在于让机器替我们守住底线，让人专注于更有价值的创造。