Git bundle少带一段历史，接收方为何反而必须先有它

Git的git-bundle手册将bundle用于离线传递对象：网络另一侧不必有一个正在运行的服务器，历史可以由这个文件承载。它能够用于完整或增量的传递，也能把一处仓库引用的状态交给另一处。本文讨论这个文件需要哪些对象，而不是演示创建或导入命令。[1]

文件内部不只是普通源码压缩包。BUNDLE FORMAT说明，它包含pack对象数据，以及指出包中有哪些references的头部。引用说明历史从哪些端点被提及，对象数据则承载相应内容。这两部分共同解释了为何bundle既能被当作读取历史的来源，又有自身需要说明的引用范围。[1]

自包含包所覆盖的范围，从选定修订的可达对象开始。手册说，只指定这一修订的情形会包含通向它的完整历史；这样的包可以在没有共同历史的仓库中接收，也可面向空仓库。这里的“自包含”是相对于所选历史而言，不是宣布文件已经保存了发送方电脑上的全部资料。[1]

增量包通过排除先前的历史缩小对象范围。手册用旧修订到新修订的区间解释：被排除的旧修订及其可达对象，必须已存在于接收方，包才能被接收。这些对象没有出现在本次传来的包中，却仍是使用包内新历史的前提。因而，包里少了一段，不表示那段历史从此不再需要，只是它应由接收方已有的对象补足。[1]

多个引用与多个前提也可以同时出现。官方将包中对象概括为不在各项前提并集中的对象。这项关系说明，一份增量记录的范围不能只由“比上次小”来表达，还需知道哪些前提已被排除。手册另说，包内若包含了接收方已经有的重复对象，解包时会忽略它们；重复存在与前提缺失是两种不同情况。[1]

verify的定义对应后一项条件。它既检查bundle文件本身的格式，也检查前提提交是否在当前接收仓库中存在、并且完整连接，必要时列出缺失提交。因此，“文件格式有效”与“这个接收方已有前提”需要一起说明。本文解释的是手册规定的检查范围，没有验证任何真实bundle，更没有取得项目备份可恢复的证明。[1]

手册的full backup例又限定了“全部”的对象：它指全部引用及从这些引用可达的提交，而非索引、工作树、仓库配置或hooks等其他本地状态。这一段不改变自包含包与增量包的区别；它提醒读者，历史对象范围完整，仍不等于整个本地工作现场已经被复制。[1]

读取方向也有边界。官方说，一些读取Git对象的工具能够从bundle取得资料，但没有对应的向bundle进行push写入的支持。因此，它所承担的是文件中的历史交付对象，而不是只要放在那里就具备双向写入能力的活动服务器。[1]

本文依据该手册所列2.48.0后至2.56.0无变化的内容，首次发表日未知。没有执行Git、复制仓库或安排备份恢复。