Reduce repository size

Reduce repository size
Reduce repository size

Reduce repository size

原文：https://docs.gitlab.com/ee/user/project/repository/reducing_the_repo_size_using_git.html

Purge files from repository history
Purge files from GitLab storage
Repository cleanup
Storage limits

Reduce repository size

随着时间的流逝，Git 存储库变得越来越大. 将大文件添加到 Git 存储库后：

由于每个人都必须下载文件，因此获取存储库的速度变慢.
它们占用服务器上的大量存储空间.
可以达到 Git 仓库的存储限制.

重写存储库可能会删除不需要的历史记录，从而使存储库更小. git filter-repo是用于快速重写 Git 存储库历史记录的工具，建议同时使用以下两种工具：

危险：重写存储库历史记录是一种破坏性操作. 在开始之前，请确保备份您的存储库. 备份存储库的最佳方法是导出项目 .注意： Git LFS 文件只能由管理员使用Rake 任务删除. 计划消除此限制.

Purge files from repository history

为了使克隆项目更快，请重写分支和标签以删除不需要的文件.

使用受支持的程序包管理器或从源代码安装git filter-repo .

使用--bare克隆存储库的新副本：

git clone --bare https://example.gitlab.com/my/project.git

使用git filter-repo ，从存储库的历史记录中清除所有文件.

要清除大文件，可以使用--strip-blobs-bigger-than选项：
```
git filter-repo --strip-blobs-bigger-than 10M
```
要清除使用 Git LFS 存储的大文件，可以使用--blob--callback选项. 下面的示例使用回调从 Git LFS 指针读取文件大小，并删除大于 10MB 的文件.
```
git filter-repo --blob-callback '
  if blob.data.startswith(b"version https://git-lfs.github.com/spec/v1"):
    size_in_bytes = int.from_bytes(blob.data[124:], byteorder="big")
    if size_in_bytes > 10*1000:
      blob.skip()
  '
```
要按路径清除特定的大文件，可以组合使用--path和--invert-paths选项：
```
git filter-repo --path path/to/big/file.m4v --invert-paths
```
有关更多示例和完整文档，请参见git filter-repo文档.
运行git filter-repo会删除所有遥控器. 要为您的项目还原遥控器，请运行：
```
git remote add origin https://example.gitlab.com/<namespace>/<project_name>.git
```
强制推送更改以覆盖 GitLab 上的所有分支：
```
git push origin --force --all
```
受保护的分支将导致此操作失败. 要继续，您必须删除分支保护，推送，然后重新启用受保护的分支.
要从标记的发行版中删除大文件，请强制将更改推送到 GitLab 上的所有标记：
```
git push origin --force --tags
```
受保护的标签将导致此操作失败. 要继续，您必须删除标签保护，推送，然后重新启用受保护的标签.
手动执行项目整理

注意：为提高性能而缓存了项目统计信息. 您可能需要等待 5 到 10 分钟才能看到存储利用率下降.

Purge files from GitLab storage

要减少 GitLab 中存储库的大小，必须删除 GitLab 内部引用以包含大文件的提交. 在完成这些步骤之前，请从存储库历史记录中清除文件 .

除了分支和标签（这是一种 Git 引用）之外，GitLab 还会自动创建其他引用. 这些引用可防止在查看合并请求时死链接到提交或丢失差异. 存储库清理可用于从 GitLab 中删除它们.

以下内部参考文献不做广告：

refs/merge-requests/*用于合并请求.
refs/pipelines/* for pipelines.
refs/environments/*用于环境.

这意味着在获取时通常不包含它们，这使得获取速度更快. 另外， refs/keep-around/*是隐藏的 refs，以防止与讨论相关的提交被删除并且根本无法被获取.

但是，可以从项目导出内的 Git 捆绑包访问这些引用.

使用受支持的程序包管理器或从源代码安装git filter-repo .
从项目中生成一个新的导出并下载.
使用tar解压缩备份：
```
tar xzf project-backup.tar.gz
```
这将包含一个由git bundle创建的project.bundle文件.

从包中克隆存储库的新副本：

git clone --bare --mirror /path/to/project.bundle

使用git filter-repo ，从存储库的历史记录中清除所有文件. 因为我们正在尝试删除内部引用，所以我们将依靠每次运行生成的commit-map来告诉我们要删除哪些内部引用.

注意： git filter-repo每次运行都会创建一个新的commit-map文件，并覆盖前一次运行的commit-map . 每次运行都将需要此文件. 每次运行git filter-repo都要执行下一步.

要清除所有大文件，可以使用--strip-blobs-bigger-than选项：
```
git filter-repo --strip-blobs-bigger-than 10M
```
要按路径清除特定的大文件，可以组合使用--path和--invert-paths选项.
```
git filter-repo --path path/to/big/file.m4v --invert-paths
```
有关更多示例和完整文档，请参见git filter-repo文档.
运行存储库清理 .

Repository cleanup

在 GitLab 11.6 中引入 .

仓库清理允许您上传对象的文本文件，并且 GitLab 将删除对这些对象的内部 Git 引用. 您可以使用git filter-repo生成对象列表（在commit-map文件中），该对象列表可与存储库清理一起使用.

要清理存储库：

转到存储库的项目.
导航 设置>存储库 .
上载对象列表. 例如，一个commit-map文件.
Click 开始清理.

这将：

删除所有对旧提交的内部 Git 引用.
针对存储库运行git gc .

完成后，您将收到一封电子邮件.

When using repository cleanup, note:

项目统计信息已缓存. 您可能需要等待 5 到 10 分钟才能看到存储利用率下降.
客房部修剪 2 周以上的松散物品. 这意味着在最近 2 周内添加的对象将不会立即删除. 如果您有权访问Gitaly服务器，则可以运行git gc --prune=now立即修剪所有松散的对象.
此过程将从 GitLab 的缓存和数据库中删除一些重写提交的副本，但是覆盖范围仍然存在许多空白，并且某些副本可能会无限期地存在. 清除实例缓存可能有助于删除其中的一些实例，但出于安全考虑，不应依赖它！

Storage limits

储存库大小限制：

可以由管理员在自我管理实例上设置.
Are set for GitLab.com.

当项目达到其大小限制时，您不能：

推送到项目.
创建一个新的合并请求.
合并现有的合并请求.
上载 LFS 对象.

您仍然可以：

创造新问题.
克隆项目.

如果超出存储库大小限制，则可以尝试：

删除一些数据.
进行新的提交.
推回存储库.

也许您还可以：

将一些斑点移到 LFS.
从历史记录中删除一些旧的依赖项更新.

不幸的是，该工作流程无法正常工作. 实际上，在提交中删除文件并不会减小存储库的大小，因为早期的提交和 Blob 仍然存在.

您需要做的是重写历史记录. 我们建议使用开源社区维护的工具git filter-repo .

注意：在 GitLab 端运行git gc之前，”已删除”的提交和 blob 仍将存在. 您还必须能够将重写的历史记录推送到 GitLab，如果您已经超过最大大小限制，则可能无法实现.

为了解除这些限制，自我管理的 GitLab 实例的管理员必须增加对超出它的特定项目的限制. 因此，最好始终主动保持在限制之下. 如果您达到了极限，并且无法暂时提高极限，则唯一的选择是：

在本地修剪所有不需要的东西.
在 GitLab 上创建一个新项目，然后开始使用它.

Caution: This process is not suitable for removing sensitive data like password or keys from your repository. Information about commits, including file content, is cached in the database, and will remain visible even after they have been removed from the repository.