设置和配置
获取和创建项目
基本快照
分支和合并
共享和更新项目
检查和比较
补丁
调试
电子邮件
外部系统
服务器管理
指南
管理
管道命令
- 2.41.1 → 2.47.0 无更改
-
2.41.0
06/01/23
- 2.38.1 → 2.40.3 无更改
-
2.38.0
10/02/22
- 2.36.1 → 2.37.7 无更改
-
2.36.0
04/18/22
- 2.34.1 → 2.35.8 无更改
-
2.34.0
11/15/21
- 2.33.2 → 2.33.8 无更改
-
2.33.1
10/12/21
- 2.29.1 → 2.33.0 无更改
-
2.29.0
10/19/20
- 2.25.1 → 2.28.1 无更改
-
2.25.0
01/13/20
- 2.18.1 → 2.24.4 无更改
-
2.18.0
06/21/18
- 2.9.5 → 2.17.6 无更改
-
2.8.6
07/30/17
- 2.1.4 → 2.7.6 无更改
-
2.0.5
12/17/14
概要
git bundle create [-q | --quiet | --progress] [--version=<version>] <file> <git-rev-list-args> git bundle verify [-q | --quiet] <file> git bundle list-heads <file> [<refname>…] git bundle unbundle [--progress] <file> [<refname>…]
描述
创建、解包和操作“捆绑”文件。捆绑用于在没有活动“服务器”位于网络连接另一端的情况下“脱机”传输 Git 对象。
它们可用于创建存储库的增量和完整备份，以及将一个存储库中的引用状态中继到另一个存储库。
通过 ssh:// 和 https:// 等协议获取或以其他方式“读取”的 Git 命令也可以在捆绑文件上运行。可以使用 git-clone[1] 从捆绑包中克隆一个新存储库，使用 git-fetch[1] 从捆绑包中获取，并使用 git-ls-remote[1] 列出捆绑包中包含的引用。没有相应的“写入”支持，即不支持将git push推送到捆绑包中。
有关如何使用捆绑包的示例，请参见下面的“示例”部分。
捆绑包格式
捆绑包是.pack 文件（参见 git-pack-objects[1]），包含一个标题，指示捆绑包中包含哪些引用。
与打包存档格式本身一样，捆绑包可以是自包含的，也可以使用排除项创建。请参见下面的“对象先决条件”部分。
使用修订排除项创建的捆绑包是使用 git-pack-objects[1] 的 --thin 选项创建的“瘦包”，使用 git-index-pack[1] 的 --fix-thin 选项解包。
使用修订排除项时，没有创建“厚包”的选项，用户无需关注差异。通过使用“瘦包”，使用排除项创建的捆绑包的大小更小。在此仅将它们在幕后是“瘦包”作为一种奇闻轶事以及对其他文档的引用进行说明。
有关更多详细信息，请参见 gitformat-bundle[5]，有关“瘦包”的讨论，请参见 gitformat-pack[5]。
选项
- create [选项] <file> <git-rev-list-args>
-
用于创建名为file的捆绑包。这需要<git-rev-list-args> 参数来定义捆绑包内容。options 包含特定于git bundle create 子命令的选项。如果file 是
-，则捆绑包将写入标准输出。 - verify <file>
-
用于检查捆绑包文件是否有效，并将干净地应用到当前存储库。这包括对捆绑包格式本身进行检查，以及检查先决条件提交是否存在并在当前存储库中完全链接。然后，git bundle 打印丢失的提交列表（如果有）。最后，打印有关附加功能的信息，例如“对象过滤器”。有关更多信息，请参见 gitformat-bundle[5] 中的“功能”。成功时的退出代码为零，但如果捆绑包文件无效，则退出代码将不为零。如果file 是
-，则捆绑包将从标准输入读取。 - list-heads <file>
-
列出捆绑包中定义的引用。如果后面跟着一个引用列表，则只打印与给定引用匹配的引用。如果file 是
-，则捆绑包将从标准输入读取。 - unbundle <file>
-
将捆绑包中的对象传递给git index-pack 以存储在存储库中，然后打印所有定义的引用的名称。如果给出一个引用列表，则只打印与列表中引用匹配的引用。此命令实际上是管道命令，旨在仅由git fetch 调用。如果file 是
-，则捆绑包将从标准输入读取。 - <git-rev-list-args>
-
可接受的git rev-parse 和git rev-list（并包含命名引用，请参见下面的指定引用）的参数列表，用于指定要传输的特定对象和引用。例如，
master~10..master会将当前的 master 引用与自其第 10 个祖先提交以来添加的所有对象一起打包。打包的对象和引用的数量没有明确限制。 - [<refname>…]
-
用于限制报告为可用的引用的引用列表。这主要用于git fetch，它期望只接收所请求的引用，而不必接收包中的所有内容（在这种情况下，git bundle 的作用类似于git fetch-pack）。
- --progress
-
当进度状态附加到终端时，默认情况下，它将在标准错误流上报告，除非指定 -q。此标志即使标准错误流未定向到终端，也会强制进度状态。
- --version=<version>
-
指定捆绑包版本。版本 2 是较旧的格式，只能与 SHA-1 存储库一起使用；较新的版本 3 包含允许扩展的功能。默认值为最旧的支持格式，基于所用哈希算法。
- -q
- --quiet
-
此标志使命令不再在标准错误流上报告其进度。
指定引用
修订必须与引用名称一起打包到捆绑包中。
可以打包多个引用，并可以指定多个先决条件对象集。打包的对象是那些不在先决条件并集中的对象。
git bundle create 命令使用与 git rev-parse --abbrev-ref=loose 相同的规则为您解析引用名称。每个先决条件都可以显式指定（例如 ^master~10），也可以隐式指定（例如 master~10..master、--since=10.days.ago master）。
所有这些简单情况都可以（假设我们有“master”和“next”分支）
$ git bundle create master.bundle master $ echo master | git bundle create master.bundle --stdin $ git bundle create master-and-next.bundle master next $ (echo master; echo next) | git bundle create master-and-next.bundle --stdin
这些情况也可以（以及省略了 --stdin 的示例）
$ git bundle create recent-master.bundle master~10..master $ git bundle create recent-updates.bundle master~10..master next~5..next
修订名称或其右侧无法解析为引用的范围将不被接受
$ git bundle create HEAD.bundle $(git rev-parse HEAD) fatal: Refusing to create empty bundle. $ git bundle create master-yesterday.bundle master~10..master~5 fatal: Refusing to create empty bundle.
对象先决条件
创建捆绑包时，可以创建一个自包含的捆绑包，该捆绑包可以在没有共同历史记录的存储库中解包，还可以提供负修订以排除早期历史记录中需要的对象。
将 new 之类的修订提交给 git bundle create 会创建一个捆绑包文件，其中包含从 new 修订开始可以到达的所有对象。该捆绑包可以在任何存储库中解包，以获得通向 new 修订的完整历史记录。
$ git bundle create full.bundle new
old..new 之类的修订范围将生成一个捆绑包文件，该文件需要 old 修订（以及可以从此修订开始到达的所有对象）存在，才能使捆绑包“解包”
$ git bundle create full.bundle old..new
没有先决条件的自包含捆绑包可以提取到任何地方，即使是空的存储库，也可以从它克隆（即，new，但不是 old..new）。
在谨慎方面犯错是可以的，这会导致捆绑包文件包含目标中已有的对象，因为这些对象在目标中解包时会被忽略。
如果要匹配 git clone --mirror，它将包含您的引用（例如 refs/remotes/*），请使用 --all。如果要提供与直接从源存储库克隆获得的相同引用集，请对 <git-rev-list-args> 使用 --branches --tags。
git bundle verify 命令可用于检查接收方存储库是否具有捆绑包所需的先决条件提交。
示例
假设您要将机器 A 上存储库 R1 中的历史记录传输到机器 B 上的另一个存储库 R2。由于某种原因，不允许 A 和 B 之间的直接连接，但我们可以通过某种机制（CD、电子邮件等）将数据从 A 移动到 B。我们希望使用 R1 上的 master 分支上进行的开发来更新 R2。
为了启动此过程，您首先可以创建一个没有任何先决条件的包。您可以使用一个标签来记录您上次处理的提交，以便在以后使用增量包更新另一个仓库时更容易。
machineA$ cd R1 machineA$ git bundle create file.bundle master machineA$ git tag -f lastR2bundle master
然后您将 file.bundle 传输到目标机器 B。由于此包不需要提取任何现有的对象，因此您可以在机器 B 上通过克隆创建一个新的仓库。
machineB$ git clone -b master /home/me/tmp/file.bundle R2
这将在生成的仓库中定义一个名为“origin”的远程仓库，使您能够从包中获取和拉取。R2 中的 $GIT_DIR/config 文件将包含如下条目
[remote "origin"]
url = /home/me/tmp/file.bundle
fetch = refs/heads/*:refs/remotes/origin/*
要更新生成的 mine.git 仓库，您可以在将存储在 /home/me/tmp/file.bundle 的包替换为增量更新后获取或拉取。
在原始仓库中进行更多操作后，您可以创建一个增量包来更新另一个仓库。
machineA$ cd R1 machineA$ git bundle create file.bundle lastR2bundle..master machineA$ git tag -f lastR2bundle master
然后您将包传输到另一台机器，以替换 /home/me/tmp/file.bundle，并从它中拉取。
machineB$ cd R2 machineB$ git pull
如果您知道目标接收者仓库应该拥有哪些必要对象的提交，您可以使用此信息来指定先决条件，从而提供一个截止点以限制结果包中包含的修订和对象。前面的示例为此目的使用了 lastR2bundle 标签，但您可以使用任何其他选项，就像您使用 git-log[1] 命令一样。以下是一些其他示例。
您可以使用两个仓库中都存在的标签。
$ git bundle create mybundle v1.0.0..master
您可以使用基于时间的先决条件。
$ git bundle create mybundle --since=10.days master
您可以使用提交的数量。
$ git bundle create mybundle -10 master
您可以运行 git-bundle verify 来查看您是否可以从使用先决条件创建的包中提取。
$ git bundle verify mybundle
这将列出您必须拥有的提交才能从包中提取，如果缺少任何提交则会报错。
从接收者仓库的角度来看，一个包就像一个普通的仓库，它可以从中获取或拉取。例如，您可以在获取时映射引用。
$ git fetch mybundle master:localRef
您还可以查看它提供的引用。
$ git ls-remote mybundle
GIT
是 git[1] 套件的一部分
