我有一个非常大的[大于1 GB]的git存储库，当我们必须在新的本地实例上设置存储库时总会出现问题。有没有经过验证的方法，以便我们可以解决这个问题？
答案 0 :(得分：1)
设置＆＃34;仓库＆＃34;克隆存储库，其旧历史记录在共享文件系统上不会发生变化。进行所有进一步的克隆--reference，将回购及其内容复制到新克隆中。阅读克隆文档以查看此用法建议，例如：在失去（或者如果你可能失去）访问你的参考仓库之前该做什么。
答案 1 :(得分：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之类的东西克隆单个分支，这样只会在指定的仓库中下拉主分支的历史记录。
https://www.atlassian.com/blog/git/handle-big-repositories-git还有一些细节可能会有所帮助 - 特别是如果您正在处理拥有大量二元资产的回购网站。
答案 2 :(得分：0)
现在有 microsoft/scalar （它是started three years ago as GVFS，然后是VFS for Git，即moved in its own repository。
现在，since August 2019, Scalar）
标量：Git的一组工具和扩展，可以在没有虚拟化层的情况下在Git上运行非常大的Monorepos
如果您的回购托管在支持GVFS Protocol的服务（例如Azure Repos）上，则
scalar clone <url>将创建具有按需对象功能的本地征募检索，后台维护任务，并自动设置Git配置值和挂钩以提高性能。
标量还可以帮助建立稀疏征募。
在Git 2.27（2020年第二季度）中，“ git fetch”为scalar clone提供了更好的支持。
它还说明了scalar clone与常规git clone的不同之处，并将处理更大的存储库。
请参见commit b739d97的Derrick Stolee (derrickstolee)（2020年3月13日）。
（由Junio C Hamano -- gitster --在commit 4cd9bb4中合并，2020年3月25日）
connected.c：用于特殊情况的重复包装帮助者：杰夫·金
帮助者：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()内部的循环（该循环检查是否所有承诺都包含在承诺包中）实际上在packed_git列表中没有任何包文件。我不确定是什么极端情况引起了此配置选项，以防止在获取操作期间在适当的位置调用
reprepare_packed_git()。这种方法需要我们使用远程帮助程序的情况，这使得测试变得困难。可以在获取代码的位置更靠近提取代码的位置放置一个
reprepare_packed_git()调用，但这为以后的更改留出了空间以重新引入此问题。
此外，并发重新打包操作可能会替换我们已经加载到内存中的打包文件列表，从而在更难以重现的情况下导致此问题。任何人在打包文件列表中循环查找某个对象，以至于在找不到时回落到
reprepare_packed_git()的情况下，这实际上都是责任。check_connected()中的循环没有此后备功能，从而导致此错误。我们
_could_尝试循环浏览这些数据包，仅在未命中后重新打包这些数据包，但是这种更改涉及的更多，而且价值不大。
由于这种情况与opt->check_refs_are_promisor_objects_only为true的情况是孤立的，因此我们有信心在下载新数据后将对refs进行验证。这意味着，与已经进行的其余操作相比，提前调用reprepare_packed_git()不会花费很多。