捆绑 git 存储库而不克隆它

Question

如何捆绑 git 项目而不需要每次都克隆它？现在我总是执行下面的命令。

git clone --mirror http://git_project
cd git_project
git bundle create '../git_project.lock' --all
cd ..
rm git_project -Force -Recurse

我想用一个命令来完成此操作，例如：

git bundle create '../git_project.lock' --all --repository http://git_project

Answer 1

\n

我将把这些捆绑文件作为另一台计算机上的备份

\n

\n

自从我 2011 年的回答（十一年前）以来，您现在拥有像GitHub Actions或GitLab CI这样的远程管道。

\n

这些远程 Git 存储库托管服务上的自动化管道可以为您创建捆绑包并将其保存到服务器/备份中。

\n

那就是今天。

\n\n

明天，您将能够使用“ git bundle ”专用服务器，通过捆绑包 URI进行访问。

\n

在 Git 2.38（2022 年第 3 季度）中，“bundle URI”设计被记录下来。

\n

请参阅Derrick Stolee ( )提交的 d06ed85和2da14fa 提交（2022 年 8 月 9 日）。\n ^{（由Junio C Hamano 合并 -- --在提交 0d133a3，2022 年 8 月 18 日）}derrickstolee
gitster

\n

\n

docs：文档包 URI 标准

\n

^{签署人：Derrick Stolee}

\n

\n

\n

通过理想的设计文档将捆绑 URI 的想法引入 Git 代码库。
\n本文档包含完整的设计，旨在以完全实现的形式包含该功能。
\n这将采取实施计划部分中详细说明的几个步骤。

\n

通过现在提交此文档，它可以用来激励实现这些最终目标所需的更改。
\n随着新​​信息的发现，设计仍然可以改变。

\n

\n

technical/bundle-uri现在包含在其手册页中：

\n

\n

捆绑 URI

\n

Git 捆绑包是存储包文件以及一些额外元数据的文件，\n包括一组引用和一组（可能为空）必要的提交。git bundle有关更多信息，请参阅\n和链接：bundle-format.txt[捆绑包格式]。

\n

捆绑包 URI 是 Git 可以下载一个或多个捆绑包的位置，\n以便在从远程获取\n剩余对象之前引导对象数据库。

\n

目标之一是加快与源服务器网络连接较差的用户的克隆和获取速度。另一个好处是允许重度用户（例如 CI 构建场）使用本地资源来处理大部分 Git 数据，从而减少源服务器上的负载。

\n

要启用捆绑 URI 功能，用户可以使用命令行选项\n指定捆绑 URI，或者源服务器可以\n通过协议 v2 功能通告一个或多个 URI。

\n

\n

\n

也可以看看

\n

\n

• 早期关于捆绑 URI 功能的 RFC。

  \n
\n

• GVFS协议

  \n
\n

\n

\n

和：

\n

\n

bundle-uri：添加示例包组织

\n

^{签署人：Derrick Stolee}

\n

\n

\n

添加一个部分，详细说明捆绑包提供程序如何工作，包括对多个地理分布式服务器使用 Git 服务器广告。
\n该组织基于 GVFS 缓存服务器，该服务器已成功使用类似的想法为非常大的存储库提供快速对象访问并减少服务器负载。

\n

\n

technical/bundle-uri现在包含在其手册页中：

\n

\n

捆绑包提供商组织示例

\n

此示例组织是 GVFS 缓存服务器所使用的简化模型（请参阅本文档末尾附近的部分），尽管在吉特。

\n

捆绑包提供商跨多个地理位置部署服务器。
\n每个服务器管理自己的捆绑包集。

\n

服务器可以跟踪多个 Git 存储库，但根据模式为每个存储库提供一个捆绑列表。

\n

例如，当在https://<domain>/<org>/<repo>\n镜像存储库时，捆绑包服务器可以在\n处获得其捆绑包列表https://<server-url>/<domain>/<org>/<repo>。
\n源 Git 服务器可以\n在“任意”模式下列出所有这些服务器：

\n

[bundle]\nversion = 1\nmode = any\n\n[bundle "eastus"]\nuri = https://eastus.example.com/<domain>/<org>/<repo>\n\n[bundle "europe"]\nuri = https://europe.example.com/<domain>/<org>/<repo>\n\n[bundle "apac"]\nuri = https://apac.example.com/<domain>/<org>/<repo>\n

\n

此“列表的列表”是静态的，并且仅在添加或删除捆绑服务器时才会更改。

\n

捆绑包服务器定期运行捆绑包列表更新，\n例如每天一次。
\n在此任务期间，服务器从源服务器获取最新\n内容并生成一个包，其中包含\n可从最新源引用访问的对象，但不包含在\n之前计算的包中。
\n此捆绑包将添加到列表中，\n请注意\ncreationToken严格大于先前的最大值\n creationToken。

\n

此处提供了示例捆绑包列表，尽管它只有两个每日捆绑包，而不是 30 个捆绑包的完整列表：

\n

[bundle]\nversion = 1\nmode = all\nheuristic = creationToken\n\n[bundle "2022-02-13-1644770820-daily"]\nuri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644770820-daily.bundle\ncreationToken = 1644770820\n\n[bundle "2022-02-09-1644442601-daily"]\nuri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-09-1644442601-daily.bundle\ncreationToken = 1644442601\n\n[bundle "2022-02-02-1643842562"]\nuri = https://eastus.example.com/<domain>/<org>/<repo>/2022-02-02-1643842562.bundle\ncreationToken = 1643842562\n

\n

这种数据组织的意图有两个主要目标。

\n

\n

• 首先，通过从更近的源下载预先计算的对象数据，存储库的初始克隆变得更快。

  \n
\n

• 其次，git fetch命令可以更快，\n尤其是在客户端几天没有获取数据的情况下。但是，如果客户端 30 天没有获取数据，则捆绑列表组织将导致重新下载大量对象数据。

  \n
\n

\n

\n\n

这是实现的（仍然使用 Git 2.38 (Q3 2022)）：“ git clone --bundle-uri” ^{( man )}。

\n

请参阅提交 65da938（2022 年 8 月 23 日），以及提交 e21e663、提交 59c1752、提交 5556891、提交 53a5089、提交 b5624a4（2022 年 8 月 09 日），作者：Derrick Stolee ( derrickstolee)。
\n ^{（由Junio C Hamano 合并 -- gitster--在提交 68ef042中，2022 年 9 月 1 日）}

\n

\n

clone: 添加 --bundle-uri 选项

\n

^{审阅者：Josh Steadmon}
\n^{签署者：Derrick Stolee}

\n

\n

\n

克隆远程存储库是 Git 中最昂贵的操作之一。
\n服务器可能会花费大量 CPU 时间来为客户端的请求生成包文件。
\n数据量大会导致网络长时间堵塞，而且Git协议不可断点续传。
\n对于网络连接较差或距离源服务器较远的用户来说，这可能会特别痛苦。

\n

将新的 \' --bundle-uri\' 选项添加到 \' git clone\' ^{( man )}以从捆绑包引导克隆。
\n如果用户知道捆绑服务器，那么他们可以告诉 Git 在从原始服务器获取剩余对象之前使用这些捆绑引导新存储库。

\n

\n

git clone现在包含在其手册页中：

\n

\n

--bundle-uri=<uri>

\n

在从远程获取之前，请从给定的\n获取数据包<uri>并将数据解包到本地存储库中。

\n

捆绑包中的引用将存储在隐藏的refs/bundle/*命名空间下。

\n

--depth此选项与、--shallow-since和不兼容--shallow-exclude

\n

\n\n

Git 2.39（2022 年第 4 季度）定义了“”的逻辑元素bundle list、将它们存储在核心中的数据结构、传输它们的格式以及解析它们的代码。

\n

请参阅提交 8628a84、提交 70334fc、提交 89bd7fe、提交c23f592、提交 c96060b、提交 20c1e2a、提交 738e524、提交 bff03c4、提交 0634f71、提交 23b6d00（2022 年 10 月 12 日），作者：Derrick Stolee ( derrickstolee)。
\n请参阅 \xc3\x86var Arnfj\xc3\xb6r\xc3\xb0 Bjarmason ( )的提交 d796ced和提交 9424e37（2022 年 10 月 12 日）。\n请参阅Junio C Hamano ( )提交的 f677f62（2022 年 8 月 24 日）。\n ^{（由Taylor Blau 合并 -- --在d32dd8a 提交中，2022 年 10 月 30 日）}avar
gitster
ttaylorr

\n

\n

bundle-uri：获取捆绑包列表

\n

^{签署人：Derrick Stolee}

\n

\n

\n

当给定捆绑包 URI 中的内容不被理解为捆绑包（基于检查初始内容）时，Git 目前会放弃并忽略该内容。
\n独立捆绑包提供商可能希望将捆绑包内容拆分为多个捆绑包，但仍可通过单个 URI 获取它们。

\n

教 Git 尝试将捆绑包 URI 内容解析为提供key=value捆绑包列表对的 Git 配置文件。
\n然后，Git 查看列表的模式以查看是否有任何单个捆绑包就足够，或者是否需要所有捆绑包。
\n下载所选 URI 处的内容并再次检查该内容，从而创建递归过程。

\n

为了防止递归出现格式错误或恶意内容，暂时将递归深度限制为合理的四。
\n如果需要，将来可以将其转换为配置值。
\n四的值是预期有用的两倍（捆绑列表不太可能指向更多捆绑列表）。

\n

要测试此场景，请创建一个有趣的捆绑包拓扑，其中三个增量捆绑包构建在单个完整捆绑包之上。
\n通过使用合并提交，两个中间捆绑包是“独立的”，因为它们不需要彼此来解绑自己。
\n他们每个人只需要基础包。
\n不过，包含合并提交的包需要两个中间包。
\n这会导致在分拆时做出一些有趣的决定，特别是当我们稍后实施启发式方法来促进下载捆绑包直到满足先决条件提交时。

\n

\n\n

Git 2.40（2023 年第 1 季度）继续实施捆绑 URI（第 4 部分）。

\n

请参阅提交 876094a、提交 12b0a14、提交 ebc3947、提交 9ea5796、提交 738dc7d、提交 1b759e0（2022 年 12 月 22 日），作者：Derrick Stolee ( derrickstolee)。
\n请参阅\xc3\x86var Arnfj\xc3\xb6r\xc3\xb0 Bjarmason ( )的提交 70b9c10、提交 7cce907、提交 0cfde74、提交 8f788eb、提交 8b8d9a2（2022 年 12 月 22 日）。\n ^{（由Junio C Hamano 合并 -- --提交0903d8b，2023 年 1 月 2 日）}avar
gitster

\n

\n

bundle-uri client：添加布尔transfer.bundleURI设置

\n

^{共同作者：Derrick Stolee}
\n^{签署人：\xc3\x86var Arnfj\xc3\xb6r\xc3\xb0 Bjarmason}
\n^{签署人：Derrick Stolee}

\n

\n

\n

尚未引入的对bundle-uri 的客户端支持将始终依赖于完整克隆，但我们仍然希望能够完全忽略服务器的bundle-uri 广告。

\n

新的transfer.bundleURI配置选项默认为“false”，但用户可以将其设置为“true”以启用使用协议 v2 检查来自源 Git 服务器的包 URI。

\n

\n

git config现在包含在其手册页中：

\n

\n

transfer.bundleURI

\n

当 时true，本地git clone命令将从远程服务器请求捆绑包信息（如果已公布）并下载捆绑包，然后再通过 Git 协议继续克隆。
\n默认为false.

\n

\n

和：

\n

\n

bundle-uri:bundle.* keys从配置中提供服务

\n

^{签署人：Derrick Stolee}

\n

\n

\n

key=value通过填充本地 Git 配置中的数据包行来实现“bundle-uri”协议 v2 功能。
\n捆绑包列表由以“bundle.”开头的键提供。

\n

\n

和：

\n

\n

bundle-uri: 允许捆绑列表中的相对 URL

\n

^{签署人：Derrick Stolee}

\n

\n

\n

捆绑包提供商可能希望跨多个 CDN 分发该数据。
\n这可能需要更改基本 URI，一直到域名。
\n如果所有包都需要在其 \' \' 值中包含绝对 URI uri，则每次推送到 CDN 都需要更改目录以匹配预期的域和其中的确切位置。

\n

允许捆绑包列表指定捆绑包的相对 URI。

\n

此 URI 基于客户端接收捆绑列表的位置。
\n对于 \'bundle-uri\' 协议 v2 命令中提供的列表，Git 远程 URI 是基本 URI。
\n否则，捆绑包列表是从不使用 Git 协议的 HTTP URI 提供的，并且该 URI 是基本 URI。
\n这使得捆绑数据的分发更加容易。

\n

\n\n

在 Git 2.40（2023 年第一季度）中，bundle-URI 子系统添加了对创建令牌启发式的支持，以帮助增量获取。

\n

请参阅提交 026df9e、提交 c429bed、提交 7f0cc04、提交 0524ad3、提交 4074d3c、提交 7903efb、提交 512fccf、提交 c93c3d2、提交 7bc73e7、提交 d9fd674、提交 e72171f（2023 年 1 月 31 日），作者：Derrick斯托利( derrickstolee)。
\n ^{（由Junio C Hamano 合并 -- gitster--在提交 4f59836中，2023 年 2 月 15 日）}

\n

\n

clone：如果合适的话设置 fetch.bundleURI

\n

^{签署人：Derrick Stolee}

\n

\n

\n

捆绑包提供商可能会以旨在改进增量获取（而不仅仅是初始克隆）的方式组织其捆绑包列表。
\n但是，他们确实需要声明他们已经考虑到这一点进行组织，否则客户端将不会期望通过在初始克隆后下载捆绑包来节省时间。
\n这是通过指定bundle.heuristic 值来完成的。

\n

有两种类型的捆绑列表：静态 URI 中的捆绑列表和通过协议 v2 从 Git 远程发布的捆绑列表。

\n

新的 fetch.bundleURI 配置值适用于未通过协议 v2 公布的静态捆绑包 URI。
\n如果用户通过 \' git clone --bundle-uri\' ^{( man )}指定静态 URI ，则 Git 可以将此配置设置为提醒未来的 \' \ git fetch' ⁽