如何管理大型 git repo？

Question

我有一个非常大的 git 存储库 [大于 1 GB]，当我们必须在新的本地实例上设置存储库时总是会出现问题。是否有任何行之有效的方法可以解决这个问题？

Answer 1

如果您不需要立即完整的历史记录，并且您使用的是最新版本的 Git（1.9 或更高版本），那么您可以进行浅层克隆：

• git clone --depth 5 user@host:repo.git 会将 repo 历史记录截断为每个分支上最近的 5 个提交
• git clone --shallow-since=2017-12-01 user@host:repo.git 将从 2017 年 12 月 1 日起截断回购历史记录
• git clone --shallow-exclude=abc1234 user@host:repo.git 将克隆每个修订版除了指定的版本和可以从指定的版本到达的版本。您可以多次使用--shallow-exclude 来指定多个不需要的修订。

您还可以使用git clone --branch master --single-branch user@host:repo.git 之类的内容克隆单个分支，这只会拉下指定 repo 上主分支的历史记录。

https://www.atlassian.com/blog/git/handle-big-repositories-git 提供了更多详细信息，这可能会有所帮助 - 特别是如果您正在处理具有大量二进制资产的回购。

Answer 2

设置一个“仓库”克隆存储库，其旧历史不会在共享文件系统上更改。做所有进一步的克隆--reference 那个 repo 和它的内容不会被复制到新的克隆。阅读克隆文档以查看使用建议，例如在失去（或如果您可能失去）对参考仓库的访问权之前该怎么做。

Answer 3

现在有microsoft/scalar（它是started three years ago as GVFS，然后是VFS for Git，它是moved in its own repository。
现在，since August 2019, Scalar)

Scalar：Git 的一组工具和扩展，允许在没有虚拟化层的情况下在 Git 上运行非常大的 monorepos

如果您的 repo 托管在支持 GVFS Protocol 的服务上，例如 Azure Repos，那么 scalar clone <url> 将创建具有按需对象检索、后台维护等功能的本地登记任务，并自动设置 Git 配置值和启用性能增强的挂钩。
Scalar 还有助于设置稀疏登记。

它记录在 Git 2.35（2022 年第一季度）中：

scalar: 开始记录命令

^{签字人：约翰内斯·辛德林}

Scalar 是一个固执己见的存储库管理工具。

通过使用 Scalar 创建新存储库或注册现有存储库，您的 Git 体验将会加快。
Scalar 设置高级 Git 配置设置，在后台维护您的存储库，并有助于减少通过网络发送的数据。

一个重要的标量概念是enlistment：这是项目的顶级目录。
它通常包含子目录src/，这是一个 Git 工作树。这鼓励将跟踪文件（src/ 内部）和未跟踪文件（例如构建工件（src/ 外部）分开）。

当使用名称不是 src 的 Scalar 注册现有 Git 工作树时，登记将与工作树相同。

scalar 命令实现了各种子命令，并根据子命令的不同提供不同的选项。

---

在 Git 2.27（2020 年第二季度）中，“git fetch”为scalar clone 提供了更好的支持。

它还解释了scalar clone 与常规git clone 的不同之处以及将处理更大的存储库。

参见Derrick Stolee (derrickstolee) 的commit b739d97（2020 年 3 月 13 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 4cd9bb4，2020 年 3 月 25 日）}

connected.c: 为角落的箱子重新准备包装

^{协助者：Jeff King
协助者：Junio Hamano
签字者：Derrick Stolee}

在 v2.26.0-rc0 之上更新 microsoft/git 分支并将其使用到 Scalar 中时，我注意到部分克隆存在一个极端情况错误。

“scalar clone”命令可以创建一个具有正确配置的 Git 存储库，以便使用带有“blob:none”过滤器的部分克隆。
它不是调用“git clone”，而是运行“git init”，然后在运行“git fetch”之前设置更多配置值。

在我们基于 v2.26.0-rc0 的构建中，我们注意到我们的“git fetch”命令失败了

error: https://github.com/microsoft/scalar did not send all necessary objects

如果您从“git clone --filter=blob:none <url>”创建的存储库中复制配置文件，则不会发生这种情况，但在添加配置选项“core.logAllRefUpdates = true”时会发生这种情况。

通过调试，我可以看到check_connnected() 内部的循环检查是否所有 ref 都包含在承诺包中，实际上在packed_git 列表中没有任何包文件。

我不确定是什么极端情况问题导致此配置选项阻止reprepare_packed_git() 在提取操作期间在适当的位置被调用。这种方法需要我们使用远程助手进程的情况，这使得测试变得困难。

可以将reprepare_packed_git() 调用放在更接近我们接收包的位置的提取代码中，但这为以后的更改留下了一个机会，以便重新引入这个问题。
此外，并发重新打包操作可能会替换我们已经加载到内存中的打包文件列表，从而在更难重现的情况下导致此问题。

任何人都有责任在包文件列表中循环查找某个对象以在查找失败时回退到reprepare_packed_git()。 check_connected() 中的循环没有这个回退，导致这个错误。

我们_could_ 尝试循环遍历包，仅在未命中后重新准备包，但这种更改涉及更多且价值不大。
由于这种情况与opt->check_refs_are_promisor_objects_only 为真时的情况是隔离的，因此我们有信心在下载新数据后验证参考。这意味着与已经进行的其他操作相比，提前调用reprepare_packed_git() 的成本并不高。

---

使用 Git 2.35（2022 年第一季度），将“标量”中的部分添加到 contrib/。

参见commit ddc35d8、commit 4582676、commit cb59d55、commit 4368e40、commit 546f822、commit f5f0842、commit 9187659、commit 829fe56、commit 829fe56、commit 0a43fb2、commit cd5a9ac@@（12 月 3 日） 987654343@.
见Matthew John Cheetham (mjcheetham)commit d85ada7（2021 年 12 月 3 日）。
请参阅Derrick Stolee (derrickstolee) 的commit 7020c88、commit 2b71045、commit c76a53e、commit d0feac4（2021 年 12 月 3 日）。
^{（由 Junio C Hamano -- gitster -- 合并到 commit 62e83d4，2021 年 12 月 21 日）}

scalar：实现clone子命令

^{签字人：约翰内斯·辛德林}

这实现了 Scalar 自以为是的clone 命令：它尝试使用部分克隆并默认设置稀疏结帐。
与 git clone^(man) 相比，scalar clone 在 src/ 子目录中设置工作树，以鼓励源文件和构建输出之间的分离（这对 Git 有很大帮助因为它避免了刷新索引时必须特别忽略的未跟踪文件）。

此外，它还会注册存储库以进行定期的定期维护，并根据 Microsoft Windows 和 Microsoft Office 开发团队的经验和实验配置一系列配置设置。

注意：由于scalar clone 命令是迄今为止最常用的scalar 子命令，我们将其记录在手册页的顶部。

---

Git 2.36（2022 年第二季度）包括 git scalar 的新选项：

见commit 2ae8eb5（2022 年 1 月 28 日）Johannes Schindelin (dscho)。
^{（由 Junio C Hamano -- gitster -- 合并于 commit ff6f169，2022 年 2 月 17 日）}

scalar：在子命令前接受-C 和-c 选项

^{签字人：约翰内斯·辛德林}

git 可执行文件有以下两个非常有用的选项：

-C <directory>:
在执行任何操作之前切换到指定目录

-c <key>=<value>:
临时配置此设置的持续时间 指定标量子命令

通过这次提交，我们教给 scalar 可执行文件同样的技巧。