在 GitLab 的备份文件（那个巨大的
.tar包）中，如果你将其解压，会在repositories/目录下看到大量以.bundle结尾的文件。简单来说，.bundle文件就是你的 Git 代码仓库的“单文件压缩包”。它是 Git 官方提供的一种标准离线打包格式。
.bundle 文件里到底装了什么？
每一个 .bundle 文件对应着 GitLab 中的一个代码仓库（或者 Wiki 仓库、设计仓库）。它包含了该仓库所有的 Git 数据：
- 所有的代码文件和历史版本
- 所有的提交记录（Commits）
- 所有的分支（Branches）
- 所有的标签（Tags）
⚠️ 注意它不包含的内容：
.bundle 纯粹是底层的 Git 数据。它不包含 GitLab 平台上的业务数据，比如：Issues（工单）、Merge Requests（合并请求的评论）、CI/CD 变量、用户权限等。这些业务数据全部保存在同级的数据库备份文件（database.sql.gz）中。
为什么 GitLab 备份要用 .bundle 格式？
GitLab 在执行 gitlab:backup:create 时，并没有简单粗暴地去复制 /var/opt/gitlab/git-data/ 下的文件，而是针对每一个项目悄悄执行了 git bundle create 命令。这样做有三大优势：
- 数据一致性与安全性：如果是普通的文件复制，在复制过程中如果有人刚好 push 了代码，会导致备份出来的仓库损坏。
git bundle是 Git 原生命令，能够安全地生成某个瞬间的完整快照，保证仓库绝对不会损坏。 - 极致的压缩率：
.bundle采用 Git 内部的 Delta 压缩算法，通常比直接打包（tar或zip）.git文件夹的体积要小得多。 - 标准的通用格式：
.bundle是标准的 Git 文件。这意味着，即使你的 GitLab 服务器彻底宕机且无法修复，只要你手里有这个.bundle文件，你依然可以随时把代码提取出来！
如何脱离 GitLab，手动提取 .bundle 里的代码？
这是 .bundle 文件最强大的地方。如果你急需某段代码，但 GitLab 还没搭建好，你可以直接在本地把 .bundle 当作一个远程仓库来操作。
假设你从备份中解压出了一个名叫 project.bundle 的文件，把它拷贝到你的个人电脑上，你可以执行以下操作：
验证包是否完整：
git bundle verify project.bundle直接克隆出代码（就像从线上 clone 一样）：
# 这会把 bundle 里的代码解压到一个叫 my_code 的文件夹里
git clone project.bundle my_code查看里面有哪些分支：
git ls-remote project.bundle它们在 GitLab 备份包里的结构
在现代 GitLab（包括 11.2 以后采用 Hashed Storage 哈希存储的版本）中，.bundle 文件的路径通常看起来像一堆乱码，例如：
repositories/@hashed/d4/73/d4735e3a265e16eee03f59718b9b5d03019c07d8b6c51f90da3a666eec13ab35.bundle
这是因为 GitLab 为了防止项目重命名导致文件夹移动，使用了项目 ID 的哈希值来作为存储路径。
- 以
.bundle结尾的是你的主项目代码。 - 以
.wiki.bundle结尾的是该项目的 Wiki 文档库。
总结
.bundle 文件就是 GitLab 为你的每一个项目生成的标准 Git 离线镜像包。它是你在面对灾难恢复时，确保核心代码（源码本身）绝对不丢失的最后一道底线。