Git Internals

hooks 与策略执行

理解本地 hooks 与服务端 hooks 的职责边界，帮助把提交与推送策略从“口头约定”转成“系统强制执行”。

作者 · Git 使用 12 年

适合谁看
  • 想建立稳定 Git 心智模型的学习者
  • 经常遇到历史、引用、恢复问题的开发者
前置知识
  • 会看基础命令输出
  • 知道提交、分支、HEAD 这些名词
常见风险
  • 只背底层术语却不连接到实际命令
  • 把对象、引用、工作区混成一层理解

引用与延伸阅读

  1. Githooks [官方]
  2. Git commit [官方]
  3. Git push [官方]

学完这篇你会掌握什么

  • 理解 hooks 与策略执行 的核心作用和适用场景
  • 掌握 hooks 与策略执行 的基本用法和常用参数
  • 理解本地 hooks 与服务端 hooks 的职责边界，帮助把提交与推送策略从“口头约定”转成“系统强制执行”。
  • 理解 两类 hooks 相关的概念
  • 掌握 职责边界 相关的操作
  • 知道在什么场景下使用该命令，什么场景下避免使用

Git hooks 是把流程规则嵌入仓库生命周期的机制。

先想一个问题

你每天都在用 Git 命令，但偶尔会遇到一些 '奇怪' 的行为——比如明明没改文件却被提示有改动，或者 rebase 时突然多了预期之外的冲突。你想理解 Git 底层是怎么工作的。

两类 hooks

  • 本地 hooks：在开发者机器上执行（如 pre-commit）
  • 服务端 hooks：在远端仓库接收推送时执行（如 pre-receive）
Hook 执行流Git hooks 在特定事件触发时执行脚本，是本地策略执行的最低成本方案。
触发事件
pre-commitprepare-commit-msgpost-checkout
策略检查
代码风格commit messagebranch 规范
客户端 hooks 可以被绕过，不要它们作为唯一的安全防线。

职责边界

  • 本地 hooks 适合快速反馈（格式、基础 lint）
  • 服务端 hooks 适合强制门禁（分支保护、提交策略）

常见策略落地点

  1. 提交信息格式检查
  2. 禁止直接推送受保护分支
  3. 必须关联工单或变更单

一个实践原则

“建议性规则”放本地，“必须性规则”放服务端，避免因本地绕过导致策略失效。

只依赖本地 hooks 不能形成团队强制

本地 hooks 可能被跳过或配置不一致。关键治理策略应在远端统一执行。

接下来建议继续看什么

  1. review and safe push
  2. commit message conventions
  3. pr merge strategy and platform settings

给你的练习

  1. 在一个测试仓库中练习该命令的基本用法，观察执行前后的状态变化
  2. 尝试该命令的不同参数选项，对比输出结果的差异
  3. 模拟一个需要使用该命令的实际场景，完整走一遍操作流程

延伸阅读

沿着同一主题继续深入：

相关推荐

命令专题核心
git commit 教程
命令专题核心
git push 教程
最佳实践核心
评审前整理与安全推送

上下篇

上一篇rebase 内部机制与 sequencerGit 原理
下一篇当前方向没有更多内容