Git Hooks、软件开发通用Hook（服务端/客户端）及GitHub Actions技术咨询

一、Git Hooks 定义 #

Git Hooks 是 Git 原生自带的脚本触发机制，能在你执行 commit、push、checkout 等核心 Git 操作的前后，自动运行你预先编写的自定义脚本。它不需要额外依赖第三方工具，本质就是藏在本地仓库 .git/hooks 目录下的可执行脚本（默认是示例脚本，后缀为 .sample，去掉后缀就能生效），用来自动化完成代码校验、流程管控、环境同步等工作，帮团队守住代码规范和流程底线。

二、通用 Git Hooks 类型（客户端 + 服务端） #

客户端 Hooks（本地仓库触发） #

这类 Hooks 只在开发者本地仓库生效，主要用来在代码提交到远程前做前置校验：

• pre-commit：执行 git commit 前触发，是最常用的钩子之一。比如跑 ESLint/Pylint 做代码格式检查、执行单元测试、检查暂存区代码是否包含敏感信息（比如密钥），只要脚本返回非0值，就直接阻止提交。前端项目里常用 husky + lint-staged 配置，只校验暂存区代码，效率更高。
• commit-msg：提交消息输入完成后触发，用来校验 commit 信息的格式。比如强制符合 Conventional Commits 规范（如 feat: 新增用户登录模块、fix: 修复支付回调bug），不符合就不让提交，保证团队提交历史清晰统一。
• pre-push：执行 git push 前触发，适合做全量检查，比如跑集成测试、验证分支命名是否符合规则（比如不能直接推 main 分支）、检查代码覆盖率是否达标。
• post-checkout：切换分支后触发，比如自动安装分支切换后变更的依赖（检测 package.json 或 requirements.txt 变化）、同步本地配置文件。

服务端 Hooks（远程仓库触发） #

这类 Hooks 部署在远程 Git 服务器上，用来管控所有开发者的提交行为，是团队代码规范的最后一道防线：

• pre-receive：接收 push 请求时第一个触发，只要有一个提交不符合规则，就全量拒绝整个推送。比如禁止直接推 main/master 分支、校验提交者的权限、检查所有提交的消息格式。
• update：和 pre-receive 类似，但针对单个分支生效。比如允许开发者推 dev 分支，但拒绝推 main 分支；或者限制特定用户只能推指定分支。
• post-receive：push 成功后触发，用来做后续自动化操作。比如自动把代码部署到测试环境、发送提交通知到团队群、更新项目的文档站点。

三、GitHub Actions 概念与实战示例 #

概念 #

GitHub Actions 是 GitHub 内置的 CI/CD（持续集成/持续部署）工具，完全和 GitHub 仓库集成，不需要自己搭建 CI 服务器。它能在代码提交、PR 创建、标签发布等仓库事件触发时，自动执行一系列流水线任务（比如构建、测试、部署、发布）。所有配置都通过 YAML 文件定义，放在仓库的 .github/workflows 目录下，GitHub 会自动提供虚拟机来运行你的任务。

实战示例1：前端项目自动构建部署到 GitHub Pages #

假设你有一个 Vue 前端项目，需要每次推代码到 main 分支时，自动安装依赖、构建生产包，并把产物部署到 GitHub Pages。

1. 在仓库根目录创建配置文件 .github/workflows/deploy-pages.yml：

name: 部署到GitHub Pages

# 触发条件：main分支有push或PR合并
on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  构建并部署:
    # 使用Ubuntu虚拟机运行任务
    runs-on: ubuntu-latest
    steps:
      # 1. 拉取仓库代码
      - name: 拉取代码
        uses: actions/checkout@v4
        with:
          fetch-depth: 0 # 拉取全量提交历史，避免构建时的git信息缺失

      # 2. 设置Node.js环境（指定项目使用的版本）
      - name: 配置Node环境
        uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm' # 缓存npm依赖，加速后续构建

      # 3. 安装依赖
      - name: 安装依赖
        run: npm ci # 用ci命令严格按照package-lock.json安装依赖，保证版本一致

      # 4. 构建生产包
      - name: 构建项目
        run: npm run build # 对应Vue项目package.json里的build命令

      # 5. 部署到GitHub Pages
      - name: 部署到Pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }} # GitHub自动生成的令牌，用于权限验证
          publish_dir: ./dist # Vue项目默认的构建产物目录

2. 配置 GitHub Pages：
   进入仓库的「Settings」→「Pages」，在「Source」选项中选择「GitHub Actions」，保存即可。

之后每次推代码到 main 分支，GitHub 都会自动执行这套流水线：拉代码→装依赖→构建→部署，完成后你就能通过 https://<你的GitHub用户名>.github.io/<仓库名> 访问部署好的前端页面。

实战示例2：Python项目多版本测试+代码质量检查 #

如果是 Python 项目，要确保代码在多个 Python 版本下能正常运行，同时做代码质量检查，可以用这个配置：

name: Python CI

# 触发条件：所有分支的push和PR
on: [push, pull_request]

jobs:
  测试与检查:
    runs-on: ubuntu-latest
    # 同时测试多个Python版本
    strategy:
      matrix:
        python-version: ["3.9", "3.10", "3.11"]

    steps:
      - name: 拉取代码
        uses: actions/checkout@v4
      - name: 配置Python ${{ matrix.python-version }}
        uses: actions/setup-python@v5
        with:
          python-version: ${{ matrix.python-version }}
      - name: 安装依赖
        run: |
          python -m pip install --upgrade pip
          pip install pytest flake8
          pip install -r requirements.txt
      - name: flake8代码质量检查
        run: flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
      - name: pytest单元测试
        run: pytest

每次提交代码或创建 PR 时，GitHub 会用 3.9、3.10、3.11 三个 Python 版本分别跑代码检查和单元测试，确保代码在多版本环境下的兼容性，同时守住代码质量底线。

内容的提问来源于stack exchange，提问作者KUNJ PATHAK