仓库检查

您可以使用 git fsck 来验证提交到仓库中的所有数据的完整性。GitLab 管理员可以：

• 为项目手动触发此检查。
• 安排此检查 以便为所有项目自动运行。
• 从命令行运行此检查。
• 运行用于检查 Git 仓库的 Rake task，该任务可用于对所有仓库运行 git fsck 并生成仓库校验和，以此作为比较不同服务器上仓库的一种方式。

未在命令行上手动运行的检查会通过 Gitaly 节点执行。有关 Gitaly 仓库一致性检查、某些已禁用的检查以及如何配置一致性检查的信息，请参阅 仓库一致性检查。

使用 GitLab UI 检查项目的仓库

要使用 GitLab UI 检查项目的仓库：

1. 在左侧边栏的底部，选择 管理员。
2. 选择 概览 > 项目。
3. 选择要检查的项目。
4. 在 仓库检查 部分，选择 触发仓库检查。

检查是异步运行的，因此可能需要几分钟时间，检查结果才会显示在 管理员 区域的项目页面上。如果检查失败，请参阅应对措施。

为所有项目启用仓库检查

除了手动检查仓库，您还可以将 GitLab 配置为定期运行检查：

1. 在左侧边栏的底部，选择 管理员。
2. 选择 设置 > 仓库。
3. 展开 仓库维护。
4. 启用 启用仓库检查。

启用后，GitLab 会定期对所有项目仓库和 wiki 仓库运行仓库检查，以检测可能的数据损坏。每个项目每月最多检查一次，并且新项目在创建后至少 24 小时内不会被检查。

GitLab Self-Managed 管理员可以配置仓库检查的频率。要编辑频率：

• 对于 Linux package 安装，请编辑 /etc/gitlab/gitlab.rb 文件中的 gitlab_rails['repository_check_worker_cron']。
• 对于源代码安装，请编辑 /home/git/gitlab/config/gitlab.yml 文件中的 [gitlab.cron_jobs.repository_check_worker]。

如果有任何项目的仓库检查失败，所有 GitLab 管理员都会收到一封关于此情况的电子邮件通知。默认情况下，此通知每周发送一次，时间为周日开始的午夜。

已知检查失败的仓库可以在 /admin/projects?last_repository_check_failed=1 找到。

使用命令行运行检查

您可以使用命令行在 Gitaly 服务器 上的仓库中运行 git fsck。要定位仓库：

1. 前往仓库的存储位置：

   • 对于 Linux package 安装，仓库默认存储在 /var/opt/gitlab/git-data/repositories 目录中。
   • 对于 GitLab Helm chart 安装，仓库默认存储在 Gitaly pod 内的 /home/git/repositories 目录中。

2. 确定包含您需要检查的仓库的子目录。

3. 运行检查。例如：

   sudo -u git /opt/gitlab/embedded/bin/git \
      -C /var/opt/gitlab/git-data/repositories/@hashed/0b/91/0b91...f9.git fsck --no-dangling

   错误 fatal: detected dubious ownership in repository 表示您正在使用错误的帐户运行命令。例如，root 帐户。

如果检查失败该怎么办

如果仓库检查失败，请在磁盘上的以下位置查找 repocheck.log 文件 中的错误：

• 对于 Linux package 安装，路径为 /var/log/gitlab/gitlab-rails。
• 对于自编译安装，路径为 /home/git/gitlab/log。
• 对于 GitLab Helm chart 安装，路径为 Sidekiq pod 中的 /var/log/gitlab。

如果定期仓库检查导致误报，您可以清除所有仓库检查状态：

1. 在左侧边栏的底部，选择 管理员。
2. 选择 设置 > 仓库。
3. 展开 仓库维护。
4. 选择 清除所有仓库检查。

故障排除

在进行仓库检查时，您可能会遇到以下问题。

错误：failed to parse commit from object database for commit-graph

您可能会在仓库检查日志中看到 failed to parse commit <commit SHA> from object database for commit-graph 错误。如果您的 commit-graph 缓存已过期，则会发生此错误。commit-graph 缓存是一个辅助缓存，常规的 Git 操作并不需要它。

虽然可以安全地忽略此消息，但有关更多详细信息，请参阅问题 error: Could not read from object database for commit-graph。

Dangling commit、tag 或 blob 消息

仓库检查的输出通常包含需要清理的 tag、blob 和 commit：

dangling tag 5c6886c774b713a43158aae35c4effdb03a3ceca
dangling blob 3e268c23fcd736db92e89b31d9f267dd4a50ac4b
dangling commit 919ff61d8d78c2e3ea9a32701dff70ecbefdd1d7

这在 Git 仓库中很常见。它们是由诸如强制推送到分支之类的操作产生的，因为这会在仓库中生成一个不再被任何 ref 或其他 commit 引用的 commit。

如果仓库检查失败，其输出很可能包含这些警告。请忽略这些消息，并从其他输出中找出仓库检查失败的根本原因。

GitLab 15.8 及更高版本 的检查输出中不再包含这些消息。从命令行运行时，请使用 --no-dangling 选项来抑制这些消息。