Git 不处理也不存储差异。 Git 使用并存储提交（依次存储树和 blob）和标签（通常标记提交，存储树和 blob）。
也就是说，git bundle is您正在寻找的命令：它本质上是服务器端的一半git fetch它的输出是一个文件git fetch在客户端可以读取。因此，您将生成捆绑包的机器视为服务器：您告诉它客户端已经有哪些提交，以及您认为客户端在收到客户端尚未获取的提取时应该看到的分支名称实际上运行。服务器（构建捆绑包）然后打包相同的数据git fetch会得到，如果以后git fetch实际上可以到达服务器。
然后，您将数据（例如，在 USB 记忆棒上）携带到客户端，将其插入客户端，然后在客户端上运行git fetch就客户端而言，它现在正在通过线路从位于文件内部（例如，USB 记忆棒内部）的服务器实时检索数据文件。
一个大问题是，由于 USB 记忆棒（或其他任何东西）isn't实际上是一个服务器，因此客户端实际上并没有与服务器实时对话，您必须已经获得git bundle直接在服务器上执行命令。如果您错过了任何提交，则获取将会失败。如果您包含太多提交，则获取将会成功，因此为了“正确执行”，您可以首先捆绑整个存储库或某些特定的分支集，然后在发送端保存标记以记住您捆绑的内容。因此，示例中the git bundle文档 https://git-scm.com/docs/git-bundle:
machineA$ cd R1
machineA$ git bundle create file.bundle master
machineA$ git tag -f lastR2bundle master
您现在转移file.bundle到“客户端”并可以从该文件克隆。
后来，之后machineA有新的提交，您可以运行：
machineA$ cd R1
machineA$ git bundle create file.bundle lastR2bundle..master
machineA$ git tag -f lastR2bundle master
(a) 向客户端发送新的提交，以及 (b) 更新服务器端内存中发送给客户端的提交内容。 （当然，实际的发送稍后会通过 USB 记忆棒或其他方式进行。）
该标记实际上只是任何任意提交哈希 ID，或者充当 ID 的名称，或者用于建立服务器假设客户端已经拥有的“基础提交”的其他内容。
（请注意，该捆绑包包含一个“瘦包”，即针对服务器认为客户端拥有的对象进行增量压缩的对象。客户端将根据需要增大瘦包，因为 Git 不喜欢依赖于这种增量-压缩——仅在网络连接期间允许使用精简包，包括具有此类气隙的伪造包。空基础意味着该包毕竟不是精简包，而是整个存储库。）
