CI/CD 中的 Git 优化

一句话理解

完整克隆

下载完整历史 (.git/)解压所有对象构建工作区

→CI 优化策略

优化结果

--depth 1 浅克隆缓存 .git 目录partial clone 按需获取只拉取变更的文件

CI/CD 通常只需要最新代码，不需要完整历史。浅克隆可减少 80-95% 的下载时间。

CI/CD 流水线中，Git clone 和 checkout 经常是最耗时的步骤之一，尤其是大型仓库。通过浅克隆、缓存、partial clone 等策略，可以将 Git 操作时间从分钟级降低到秒级。

为什么 CI/CD 中 Git 操作慢

完整克隆的开销

# 完整克隆下载所有历史
git clone https://github.com/large/repo.git
# 对于大型仓库：
# - 可能需要下载数 GB 数据
# - 包含所有分支、tag 的完整历史
# - 包含所有版本的二进制文件（如果没使用 LFS）

CI 环境的特殊性

• 每次都是干净的环境，没有本地缓存
• 可能只需要最新代码，不需要完整历史
• 并发构建多，Git 操作重复执行
• 网络延迟（CI 服务器与 Git 仓库可能在不同区域）

优化策略 1：浅克隆

基本用法

# 只克隆最近 1 次提交
git clone --depth 1 https://github.com/user/repo.git

# 只克隆最近 N 次提交
git clone --depth 50 https://github.com/user/repo.git

# 只克隆特定分支
git clone --depth 1 --branch main https://github.com/user/repo.git

性能对比

注意事项

# 浅克隆的限制
# - 无法访问完整历史
# - git blame 可能不完整
# - git log 只显示最近 N 条
# - 无法基于历史创建分支

# 需要完整历史时再"取消浅化"
git fetch --unshallow
# 或
git fetch --depth=1000

GitHub Actions 配置

# .github/workflows/ci.yml
name: CI
on: [push, pull_request]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1  # 浅克隆，只取最新提交

      # 如果需要完整历史（如 changelog 生成）
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # 完整克隆

GitLab CI 配置

# .gitlab-ci.yml
variables:
  GIT_DEPTH: 1  # 浅克隆

build:
  script:
    - echo "Building with shallow clone"

优化策略 2：Git 缓存

GitHub Actions 缓存

name: CI
on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      # 缓存 .git 目录（高级用法）
      - name: Cache Git
        uses: actions/cache@v4
        with:
          path: .git
          key: git-${{ runner.os }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            git-${{ runner.os }}-

使用 ccache 缓存编译（间接加速）

- name: Cache build artifacts
  uses: actions/cache@v4
  with:
    path: |
      ~/.cache/ccache
      node_modules
    key: ${{ runner.os }}-${{ hashFiles('**/lockfile') }}

GitLab CI 缓存

# .gitlab-ci.yml
cache:
  key: ${CI_COMMIT_REF_SLUG}
  paths:
    - node_modules/
    - .cache/

# 或者使用分布式缓存（Premium/Ultimate）
cache:
  key: "$CI_JOB_NAME"
  paths:
    - .git/
  policy: pull-push

优化策略 3：Partial Clone

什么是 Partial Clone

Partial clone 是 Git 2.19+ 引入的特性，允许延迟获取对象：

# 不下载 blob（文件内容），只下载元数据
git clone --filter=blob:none https://github.com/user/repo.git

# 不下载大文件
git clone --filter=blob:limit=1m https://github.com/user/repo.git

# 按需下载（访问文件时自动获取）
# 第一次访问文件时会从远端获取

性能对比

GitHub Actions 中使用

- uses: actions/checkout@v4
  with:
    fetch-depth: 1
    filter: "blob:none"  # partial clone

GitLab CI 中使用

before_script:
  # 手动执行 partial clone
  - git clone --filter=blob:none --depth 1 $CI_REPOSITORY_URL .

优化策略 4：只拉变更

使用 fetch 替代 clone

如果已经缓存了 .git 目录，只需拉取变更：

# 在缓存的仓库中只拉取最新变更
git fetch origin main --depth 1
git checkout FETCH_HEAD

# 或者使用 --update-head-ok
git fetch --update-head-ok origin main

CI 中的增量更新模式

#!/bin/bash
# ci-git-setup.sh

if [ -d ".git" ]; then
    # 已有仓库，只拉取变更
    echo "Updating existing repository..."
    git fetch origin ${CI_BRANCH:-main} --depth 1
    git checkout -B ${CI_BRANCH:-main} FETCH_HEAD
else
    # 首次克隆
    echo "Cloning repository..."
    git clone --depth 1 --branch ${CI_BRANCH:-main} $REPO_URL .
fi

大型仓库专项优化

使用 sparse checkout

# 只 checkout 需要的目录
git clone --depth 1 --no-checkout https://github.com/user/repo.git
cd repo
git sparse-checkout init --cone
git sparse-checkout set src/ docs/
git checkout main

GitHub Actions 中的 sparse checkout

- uses: actions/checkout@v4
  with:
    fetch-depth: 1
    sparse-checkout: |
      src/
      docs/
    sparse-checkout-cone-mode: true

LFS 优化

# CI 中可能不需要 LFS 文件
git clone --depth 1 https://github.com/user/repo.git
cd repo

# 跳过 LFS 拉取（如果不需要）
git config lfs.fetchexclude "*"

# 或者只拉取特定类型的 LFS 文件
git config lfs.fetchinclude "*.psd,*.ai"

完整 CI 配置示例

GitHub Actions 优化版

name: CI
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  build:
    runs-on: ubuntu-latest
    timeout-minutes: 30

    steps:
      # 1. 浅克隆
      - uses: actions/checkout@v4
        with:
          fetch-depth: 1
          persist-credentials: false

      # 2. 缓存依赖
      - name: Cache node modules
        uses: actions/cache@v4
        with:
          path: ~/.npm
          key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node-

      # 3. 安装依赖
      - name: Install dependencies
        run: npm ci

      # 4. 构建
      - name: Build
        run: npm run build

      # 5. 测试
      - name: Test
        run: npm test

GitLab CI 优化版

# .gitlab-ci.yml
variables:
  GIT_DEPTH: 1
  GIT_STRATEGY: clone  # 或 fetch（如果有缓存）

stages:
  - build
  - test

.build_template: &build_config
  before_script:
    - npm ci --cache .npm
  cache:
    key:
      files:
        - package-lock.json
    paths:
      - .npm/

build:
  <<: *build_config
  stage: build
  script:
    - npm run build
  artifacts:
    paths:
      - dist/
    expire_in: 1 week

test:
  <<: *build_config
  stage: test
  script:
    - npm test

性能对比数据

测试结果（5GB 仓库）

超大型仓库（50GB+）

注意事项

1. 浅克隆不适合需要完整历史的场景：changelog 生成、git blame 分析等
2. 缓存键的选择：使用 lockfile hash 而非固定键，确保依赖更新时缓存失效
3. partial clone 需要 Git 2.19+：确认 CI 环境的 Git 版本
4. sparse checkout 需要 Git 2.25+：cone 模式需要 2.27+
5. 不要过度优化：小仓库优化效果有限，优先关注构建和测试步骤

总结

推荐组合：浅克隆 + 依赖缓存 适用于 90% 的项目，是性价比最高的优化方案。