前言
传统 Code Review 的痛点：反馈周期长、审查者耗费心力在琐碎的格式和规范问题上、低级错误反复出现等。
传统的 Code Review 就像是文章写完后交给编辑进行审校；而使用 geminicli 辅助 Git 提交审查，则是在 Word 文档里内置了一个顶级的语法和风格检查器，在每次"保存"时，它都会提供专业的修改建议。
效果示例
在 for 循环中删除 key，然后调用 git commit 提交，触发 ai 审核。
准备工作
安装 Gemini Cli 且完成认证
核心机制 Git Hooks
Git Hooks 是一些在 Git 执行特定事件（如 commit, push, receive 等）时自动运行的脚本。我们正好可以利用这个特性，在代码被"提交"或"推送"之前，执行一个调用 Gemini API 的脚本来分析代码。
对于我们的需求，最合适的钩子是 pre-commit 或 pre-push：
pre-commit钩子 ：在你执行git commit命令后，但在 Git 要求你输入 commit message 之前运行。如果这个脚本以非零状态退出，Git 将会中止本次提交。这是最适合场景的钩子，因为它可以在代码进入本地仓库前就进行检查，让你有机会立即修改。pre-push钩子 ：在你执行git push命令后，但在任何代码被推送到远程仓库之前运行。如果脚本失败，推送也会被中止。这个也可用，但反馈链条比pre-commit更长一些。
具体实现
- 进入项目目录 ，然后找到
.git/hooks文件夹。 - 在该文件夹内，创建一个名为
pre-commit的文件。
注意：文件名就是pre-commit，不要带任何后缀。 - 编写脚本（内容可根据实际调整） ：
bash
#!/bin/sh
# 上面这行 #!/bin/sh 对于在 Windows 的 Git 环境中正确执行至关重要！
echo ""
echo "[AI Code Review] 正在准备代码进行 AI 分析..."
# 1. 获取所有暂存的代码变更
STAGED_DIFF=$(git diff --cached -- . ':(exclude)*.lock' ':(exclude)package*.json')
# 如果没有暂存的代码变更，则直接退出
if [ -z "$STAGED_DIFF" ]; then
echo "[AI Code Review] 没有发现暂存的代码变更。跳过分析。"
exit 0
fi
echo "[AI Code Review] 正在调用 Gemini 进行代码审查，请稍候..."
# 2. 准备发送给 Gemini 的 Prompt，并通过管道传递
# 我们将 Prompt 和代码变更内容一起通过标准输入传给 gemini 命令
AI_FEEDBACK=$(cat <<EOF | gemini
你是一名资深软件工程师，正在进行代码审查(Code Review)。
请严格、专业地分析以下代码变更(以 git diff 格式提供)。
你的分析应集中在以下几个方面：
1. **代码质量**: 是否存在冗余代码、不合理的逻辑或坏味道？
2. **潜在 Bug**: 是否有明显的逻辑漏洞、边界条件问题或空指针风险？
3. **性能优化**: 是否有可以提高性能的写法？
4. **代码规范和可读性**: 代码是否遵循通用规范？命名是否清晰？
请以清晰、简洁的要点形式给出你的建议。如果代码质量很好，没有需要修改的地方，请只回复"代码质量优秀，无修改建议。"这句话，不要添加任何其他内容。
这是需要你审查的代码变更：
\`\`\`diff
$STAGED_DIFF
\`\`\`
EOF
)
# 3. 检查 gemini 命令是否成功执行
if [ $? -ne 0 ]; then
echo ""
echo "[AI Code Review] 错误：调用 'gemini' 命令失败。"
echo "请确认 'gemini' 已经正确安装并且在其路径在系统 PATH 环境变量中。"
echo "本次提交将继续，但未进行 AI 审查。"
exit 0
fi
# 4. 显示 AI 的反馈
echo ""
echo "------------------- Gemini 代码审查报告 -------------------"
echo "$AI_FEEDBACK"
echo "-----------------------------------------------------------"
echo ""
# 5. 交互式地决定是否继续提交
# 使用 grep -q 来安静地检查字符串是否存在
if ! echo "$AI_FEEDBACK" | grep -q "代码质量优秀，无修改建议。"; then
# 在 Windows 的 Git Bash 中，需要用 -n 1 和特定的提示格式
echo "AI 提出了以上建议，你是否要中止提交以修改代码？(y/N)"
read -r answer < /dev/tty
if [ "$answer" = "y" ] || [ "$answer" = "Y" ]; then
echo "[AI Code Review] 提交已中止。请根据建议修改代码后重试。"
exit 1 # 退出码为 1，中止 git commit
else
echo "[AI Code Review] 用户选择继续提交..."
exit 0 # 退出码为 0，继续 git commit
fi
else
echo "[AI Code Review] ✅ 代码质量优秀！将自动继续提交。"
exit 0
fi- 授予执行权限 : 打开 Git Bash 终端（在项目文件夹点右键，选择
Git Bash Here）。
然后运行以下命令：
chmod +x .git/hooks/pre-commit
如何一次配置，所有项目通用？
问题： 在多个项目中维护相同的钩子脚本，如果靠复制粘贴，后期会越来麻烦。
解决： 使用全局钩子路径 (Global Hooks Path)
操作：
在电脑中任意创建 .githooks 目录(创建全局钩子目录)，并且将pre-commit脚本移动到该位置，然后执行以下命令就可以了。
js
git config --global core.hooksPath <你的目录路径>
示例：
git config --global core.hooksPath 'C:/Users/你的用户名/.githooks'优先级规则 ：这个全局设置非常智能，它不会"霸道地"覆盖所有情况。Git 的钩子查找优先级是：
- 首先 ，检查项目本地的
.git/hooks/目录。如果这里面有pre-commit脚本，就用它。 - 其次 ，如果本地没有，Git 会检查是否通过
git config core.hooksPath（不带--global）设置了项目级的钩子路径。 - 最后 ，如果以上都没有，Git 才会去查找你用
--global设置的全局钩子路径~/.githooks/。
这意味着，如果某个特定项目需要一个不同于 全局规则的钩子，你仍然可以在那个项目的 .git/hooks/ 目录里放一个专门的脚本来覆盖全局设置，提供了极大的灵活性。
如何作用于团队？
Git 2.9 版本以上支持一个名为 core.hooksPath 的配置，允许将钩子脚本存放在项目目录下的一个普通文件夹里，并让 Git 从那里读取。
-
在项目根目录创建一个新文件夹 ，比如叫
.githooks。 -
将
pre-commit脚本移动到这个新文件夹里。 -
将
.githooks文件夹添加到版本控制。 -
通知所有团队成员 ，在他们第一次拉取代码后，只需在各自的电脑上为这个项目执行一次以下命令：
arduinogit config core.hooksPath .githooks这个命令会告诉 Git："不要用默认的
.git/hooks目录了，请使用项目根目录下的.githooks文件夹作为钩子目录。"
- 优点：无需任何第三方工具，纯 Git 功能。
- 缺点：需要团队成员手动执行一次配置命令。新人加入时需要告知。
总结
通过在开发流程的最前端建立一个低成本、高效率、智能化的质量反馈机制，从而系统性地提升代码入库的基线质量，解放人类审查者去关注更有创造性的工作，最终实现研发效率和软件质量的双重飞跃。