git线下环境bundle介绍

这在许多场景中都很有用，有可能网络中断了，但又希望将我们的提交传给合作者们，我们可能不在办公网中并且出于安全考虑没有接入内网的权限，可能无线、有线网卡坏掉了，可能现在没有共享服务器的权限，然而我们又希望通过邮件将更新发送给别人，却不希望通过 format-patch 的方式传输 40 个提交。这些情况下 git bundle 就会很有用，bundle 命令会将 git push 命令所传输的所有内容打包成一个二进制文件，可以将这个文件通过邮件或者闪存传给其他人，然后解包到其他的仓库中。
来看看一个简单的例子，假设有一个包含两个提交的仓库：

如果想把这个仓库发送给其他人但没有其他仓库的权限，或者就是懒得新建一个仓库，就可以用 git bundle create 命令来打包：

然后就会有一个名为 repo.bundle 的文件，该文件包含了所有重建该仓库 master 分支所需的数据。在使用 bundle 命令时，需要列出所有希望打包的引用或者提交的区间，如果希望这个仓库可以在别处被克隆，应该像例子中那样增加一个 HEAD 引用。我们可以将这个 repo.bundle 文件通过邮件或者 U 盘传给别人。
另一方面，假设别人传给我们一个 repo.bundle 文件并希望在这个项目上工作，可以从这个二进制文件中克隆出一个目录，就像从一个 URL 克隆一样：

如果在打包时没有包含 HEAD 引用，还需要在命令后指定一个 -b master 或者其他被引入的分支，否则 Git 不知道应该检出哪一个分支。
现在假设提交了 3 个修订，并且要用邮件或者 U 盘将新的提交放在一个包里传回去：

首先我们需要确认我们希望被打包的提交区间，和网络协议不太一样，网络协议会自动计算出所需传输的最小数据集，而我们需要手动计算。当然可以像上面那样将整个仓库打包，但最好仅仅打包变更的部分，就是我们刚刚在本地做的 3 个提交。
为了实现这个目标，我们需要计算出差别，有很多种方式去指明一个提交区间，我们可以使用 “origin/master…master”或者“master ^origin/master”之类的方法来获取那 3 个在 master 分支而不在原始仓库中的提交。可以用 log 命令来测试：

这样就获取到我们希望被打包的提交列表，让我们将这些提交打包，可以用 git bundle create 命令，加上想用的文件名，以及要打包的提交区间：

现在在目录下会有一个 commits.bundle 文件，如果把这个文件发送给我们的合作者，她可以将这个文件导入到原始的仓库中， 即使在这期间已经有其他的工作提交到这个仓库中。
当她拿到这个包时，她可以在导入到仓库之前查看这个包里包含了什么内容，bundle verify 命令可以检查这个文件是否是一个合法的 Git 包，是否拥有共同的祖先来导入：

如果打包工具仅仅把最后两个提交打包，而不是三个，原始的仓库是无法导入这个包的， 因为这个包缺失了必要的提交记录。这时候 verify 的输出类似：

而我们的第一个包是合法的，所以可以从这个包里提取出提交。如果想查看这边包里可以导入哪些分支，同样有一个命令可以列出这些顶端：

verify 子命令同样可以知道哪些顶端，该功能的目的是查看哪些是可以被拉入的，所以可以使用 fetch 或者 pull 命令从包中导入提交。这里我们要从包中取出 master 分支到我们仓库中的 other-master 分支：

可以看到已经将提交导入到 other-master 分支，以及在这期间我们自己在 master 分支上的提交：

因此，当在没有合适的网络或者可共享仓库的情况下，git bundle 很适合用于共享或者网络类型的操作。