如何规范团队的Git提交？Composer结合Husky实现代码提交前校验

如何规范团队的Git提交？Composer结合Husky实现代码提交前校验

先说一个核心判断：Composer 本身并不参与 Git 提交规范。你看到的所谓“Composer + Husky”组合，其实是一个常见的误区，本质上是混淆了前端与 PHP 生态的工具链。Husky 是 Node.js 生态的 Git Hook 工具，它只在 npm 或 yarn 项目中生效。而 Composer 是 PHP 的依赖管理器，它本身不提供钩子机制，更不可能直接拦截 git commit 命令。

所以，如果你的项目是 PHP 技术栈，比如 Lara vel 或 Symfony，想要实现提交前的代码校验，就必须换一套完全不同的思路。

Husky 在 PHP 项目里根本跑不起来

道理其实很简单。Husky 的安装和运行，深度依赖 Node.js 环境：它需要 npm 或 yarn，会向 .git/hooks/ 目录写入特定的 shell 脚本，并通过 node 命令来执行。

• 一个纯粹的 PHP 项目，通常既没有 package.json，也没有 node_modules 目录。直接运行 husky install 命令，大概率会直接失败。
• 即便你强行塞入一个 package.json 文件，也违背了工程环境的一致性原则。这意味着开发者需要同时维护 PHP 和 Node.js 两套依赖与脚本环境，不仅容易出错，项目交接时也平添了许多麻烦。

实际开发中，常见的错误现象有哪些呢？

• 执行 git commit 后，没有任何校验发生，Husky 钩子静默失效。
• 检查 .git/hooks 目录，发现根本没有生成 pre-commit 文件，或者文件生成了但权限不对（这个问题在 Windows 系统上尤其突出）。
• 控制台直接报错，例如 sh: husky: command not found 或者 Cannot find module 'husky'。

PHP 项目该用什么替代 Husky？

真正可行的方案，是回归 Git 的原生能力，配合 PHP 的命令行工具。具体来说，就是使用 Git 原生钩子 + PHP CLI 工具的组合拳。

• 直接在 pre-commit 钩子里编写 shell 脚本，调用诸如 phpstan、psalm、phpcs 或 php-cs-fixer 这些 PHP 生态的代码检查工具。
• 整个过程完全不依赖 Node.js，所有校验命令都通过 php 可执行文件来运行。
• 配置统一放在项目根目录的 .git/hooks/pre-commit 文件中（注意，文件必须赋予可执行权限）。

来看一个简化的钩子内容示例：

#!/bin/sh
echo "Running PHP code style check..."
if ! vendor/bin/php-cs-fixer fix --dry-run --using-cache=no; then
  echo "❌ Code style check failed. Please run 'vendor/bin/php-cs-fixer fix' and commit again."
  exit 1
fi

这里有三个关键点需要注意：

• 工具必须已安装：php-cs-fixer 需要通过 composer require --dev friendsofphp/php-cs-fixer 命令预先安装到开发依赖中。
• 脚本权限必须正确：务必执行 chmod +x .git/hooks/pre-commit 来赋予脚本可执行权限。
• 钩子分发是难点：团队成员需要手动复制这个钩子脚本，或者通过项目初始化脚本自动安装。这一点最容易被忽略，也是 Git 原生方案不如 Husky 方便的地方——它无法自动注册钩子。

为什么不能用 commitizen + commitlint 管 PHP 提交？

理论上可以，但实操起来需要绕开 Husky，过程会比较曲折。

• commitizen 本身是一个命令行工具，只要开发者本地安装了 npm，就能运行 git cz 命令，这和项目语言无关。
• 但 commitlint 对提交信息的校验，必须挂载到 commit-msg 这个 Git 钩子上。PHP 项目没有 Husky，你就得自己手动编写一个 .git/hooks/commit-msg 脚本，并在其中调用 npx commitlint --edit $1。
• 这意味着，团队里的每个开发者都必须安装 Node.js，并确保 npx 命令可用。实际落地成本很高，而且极易出现兼容性问题，比如在 Windows 下因路径包含空格、或 PowerShell 编码问题导致 commitlint.config.js 配置文件读取失败。

因此，对于 PHP 团队而言，更现实的做法通常是以下两种：

• 用纯 PHP 的方式实现提交信息校验，例如在钩子脚本里写一段 php -r "preg_match(...)" 的正则匹配代码。
• 或者，干脆放弃强制的自动化校验，转而采用 VS Code 的提交模板功能，再配合清晰的团队约定（比如在 .gitmessage 文件中预置提交格式模板）。

在工具复杂度和长期维护成本之间做权衡，后者往往是更可持续的选择。

话说回来，真正卡住团队规范落地的，从来不是工具本身选型有多难，而是钩子如何高效分发、如何同步更新、以及出了问题谁来快速调试。Node.js 工具链在纯粹的 PHP 项目里，终究属于“外来户”，强行嫁接只会让问题变得更加隐蔽和难以排查。