gitlab api获取仓库分支(修改默认主分支未生效)

Posted on Views:

1. GitLab 分支接口的缓存是从哪来的

以 获取分支列表接口 为例：

GET /api/v4/projects/:id/repository/branches

在 GitLab 中，这类接口的结果通常会被多层缓存：

1.1 GitLab 内部缓存（核心）

  1. Rails Cache

核心redis有缓存

  • 默认后端：Redis

  • 缓存内容：

    • 分支列表
    • Commit 信息
    • 权限校验结果

  1. Gitaly

    • Git 仓库存取服务
    • 自身也有一定内存缓存

  2. API 层条件缓存

    • ETag
    • Last-Modified
    • 客户端 / 网关命中 304

1.2 外部缓存（经常被忽略）

  1. Nginx / 反向代理
  2. CDN
  3. 客户端 SDK / 浏览器

👉 所以很多“分支删了但 API 还在”的问题，本质不是 Git 没同步，而是 缓存没失效。

2. GitLab 清理分支 API 缓存的正确方式

2.1 清理 Rails Cache（最直接）

适用于：

  • 分支已删除
  • API 返回旧数据
  • Web UI 正常 / 异常皆可

方法一：GitLab Rails 控制台（推荐）

1
gitlab-rails console

执行：

1
Rails.cache.clear

✔ 立即生效
✔ 不影响仓库数据

⚠️：会清空所有 Rails 缓存（API、权限、视图）

2.2 重启 GitLab 服务（粗暴但有效）

1
gitlab-ctl restart

或者只重启核心组件：

1
2
gitlab-ctl restart puma
gitlab-ctl restart sidekiq

适合场景：

  • 单机 / 小规模 GitLab
  • 缓存状态已经混乱

2.3 清理 Redis 缓存（高风险，慎用）

先确认 Redis 是 GitLab 专用：

1
gitlab-ctl redis-cli

查看 key 数量：

1
DBSIZE

清空：

1
FLUSHALL

⚠ 风险说明：

  • 会清空 所有 GitLab 缓存

  • 可能导致：

    • 登录状态失效
    • CI 队列短暂抖动

2.4 绕过缓存

如果你是 程序调用 API，请注意：

强制避免 304 / 缓存命中

1
2
Cache-Control: no-cache
Pragma: no-cache

或 curl 示例：

1
2
3
curl -H "Cache-Control: no-cache" \
     -H "PRIVATE-TOKEN: xxx" \
     https://gitlab.example.com/api/v4/projects/1/repository/branches

总结发现：分支缓存30分钟左右