GitHub 深度功能指南

学完这篇你会掌握什么

• 知道 GitHub 除了托管代码外还有哪些核心高级功能
• 理解什么时候需要用自定义 Action、矩阵构建、环境审批
• 会用 GitHub Pages 部署文档或静态站点
• 了解 CODEOWNERS、规则集和安全特性的作用

先想一个问题

你已经在用 GitHub 托管代码仓库，但你可能遇到这些场景：

• CI 工作流中有一段逻辑需要在多个项目里复用，每次复制粘贴很麻烦
• 希望自动把文档部署到 docs.yourdomain.com
• 想让特定目录的文件必须由特定团队成员审核
• 需要确保 main 分支不能被随意 force push

这些需求 GitHub 本身就能满足，只是很多人在"会 push 代码"之后就停下来了，没有继续探索平台提供的能力。

一句话理解

GitHub 不只是 Git 托管平台——它提供了 Actions（自动化）、Pages（托管）、Projects（项目管理）、安全扫描等能力，围绕着你的仓库形成一个协作闭环。

场景一：你的 CI 逻辑需要在多个项目复用

问题

你有一个步骤需要在多个工作流中使用（比如构建 Docker 镜像）。每次都写同样的 YAML 片段很冗余，而且一处更新需要在所有仓库同步。

解决方案：自定义 Action

你可以写一个可复用的 Action，把它放到独立的仓库里，然后在工作流中引用：

# .github/actions/my-action/action.yml
name: "My Custom Action"
description: "A reusable custom action"
inputs:
  who-to-greet:
    description: "Who to greet"
    required: true
    default: "World"
outputs:
  time:
    description: "The time we greeted"
runs:
  using: "node20"
  main: "index.js"

关键区别在于：它不是完整的 workflow，而是一个可被多个 workflow 引用的构建块。比如总部的一个 CI 步骤被 10 个项目使用，只需更新 Action 仓库一个地方即可。

矩阵构建：一次测试覆盖多种环境

如果你想确保代码在 Node 18/20/22 + Ubuntu/macOS/Windows 上都能通过测试：

jobs:
  test:
    strategy:
      matrix:
        os: [ubuntu-latest, macos-latest, windows-latest]
        node: [18, 20, 22]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}
      - run: npm test

这里的逻辑是：矩阵告诉 GitHub「把同样的步骤组合在不同参数下各跑一次」。上面的配置会产生 3 × 3 = 9 个并行 job。如果某个环境失败了，你会在 CI 结果中立刻看到。

环境审批：部署到生产前需要人确认

jobs:
  deploy:
    environment: production
    steps:
      - run: ./deploy.sh

配置 environment: production 后，你可以要求在部署前必须有人审批。这样做的好处是：防止任何人随意部署到生产环境。

场景二：你想把项目文档部署为一个网站

解决方案：GitHub Pages

Pages 是 GitHub 内置的静态站点托管服务。配置好之后，每次 push 到 main 分支都会自动重新部署。

# .github/workflows/deploy.yml
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm run build
      - uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: ./out

自定义域名

如果你想用自己的域名而不是 xxx.github.io：

1. 在仓库 Settings → Pages 中填写自定义域名（如 docs.yourdomain.com）
2. 在你的 DNS 服务商添加 CNAME 记录指向 your-org.github.io

场景三：项目跟踪不应只有 Issue 列表

解决方案：GitHub Projects

Projects 提供了看板视图来跟踪 Issue 和 PR 的进度，类似 Trello 或 Jira。它有四种视图：

1. Table view：类似电子表格，适合批量编辑
2. Board view：看板，按状态列分类
3. Roadmap view：时间线视图，适合跨项目规划
4. 自动化规则：当 Issue 或 PR 状态变化时自动移动卡片

实际场景：一个团队的 PR 从 "In Review" → "Approved" → "Done" 是自动流转的，不需要手动拖拽。

场景四：代码改了，但没人 review 怎么办

解决方案：CODEOWNERS

在仓库根目录创建 .github/CODEOWNERS 文件：

* @team-core
/src/api/ @team-api
/docs/ @team-docs
*.md @docs-maintainer

这样当有人修改 src/api/ 下的文件时，GitHub 会自动把 @team-api 添加为 reviewer。你不需要在每次 PR 中手动指定审核人。

规则集：更灵活的保护策略

规则集（Rulesets）是 Branch protection 的升级版。它可以跨多个分支和标签应用规则：

• 锁定仓库配置，防止被修改
• 要求线性历史（不允许 merge commit）
• 限制特定用户的创建或删除权限

安全特性

给你的练习

1. 在你的项目里创建一个自定义 Action，把常用的 CI 步骤提取出来
2. 用 GitHub Pages 部署你的项目文档（可先尝试用默认的 xxx.github.io 域名）
3. 创建一个 CODEOWNERS 文件，为不同目录指定不同的 reviewer

继续学习

1. hosting/platform-comparison — 托管平台对比
2. hosting/gitea-setup — Gitea 自建方案
3. github/github-flow-basics — GitHub Flow 基础

延伸阅读

沿着同一主题继续深入：

• Gitea 自建 Git 服务
• Git 托管平台对比：GitHub vs GitLab vs Bitbucket
• 自建 Git 服务方案对比