在代码版本控制方面，Git 现在是首屈一指的。感谢Linus 在2015 年所做的开创性工作，从此程序员的世界发生了变化。 Git 很棒，但缺点是它不适合大型二进制文件。对于具有许多大型二进制文件的项目（例如视频游戏存储库），管理和处理存储库可能是一个令人头疼的问题。 Git 的基本设计逻辑是每次有版本更改时都会创建一个完整的文件快照，并且当大型二进制文件（例如视频）被多次修改时，Git 仓库的大小会快速增长。在同步和团队协作期间，仓库内部可能是一场噩梦，尤其是当成员第一次克隆时。
当然，Git开源社区一直在想办法解决这个问题，其中就包括Git LFS，它是该问题的一个（非根本性）解决方案。
另一种更优雅的方法是使用部分克隆。
部分克隆是Git 中的一项新功能，它取代了Git LFS，本质上是让您通过控制Git 下载（或跳过）Git 仓库对象（快照）来实现管理大文件。我们在之前的文章中介绍了部分克隆，本文详细介绍了Git 部分克隆。
一些克隆的开发得到了业界的关注和参与，包括Git领导者GitHub和GitLab，以及科技巨头微软和谷歌。 GitLab 将从12.4 开始支持beta 版本。
部分克隆显着加快了检索和克隆的速度。 Git 对象下载减少，节省了网络传输，并为本地用户节省了大量磁盘空间。
除了部分克隆之外，还有选择性下载方法。这是一种稀疏结帐，适合文件和版本较多的仓库。
探索Git 大文件仓库的历史git-annex Git 大文件仓库的历史可以追溯到2010 年的git-annex。 git-annex是用Haskell脚本编写的，它允许您将Git数据库映射到文件，从而允许用户管理Git仓库中的文件。 git-annex的设计是只存储文件名和文件，独立于Git仓库。 git仓库中存储的元数据等信息用于实现大文件的跟踪。
git-media git-media 使用Ruby 语言开发，与git-annex 本地存储大文件（媒体）并定期同步的方式不同。 git-meida 是一个用于存储大文件的中央服务器。用于与git mediasync 命令同步。
Git LFS 2015年，Git社区发布了自己的解决方案Git LFS（大文件存储），类似于git-media。
Git LFS 解决方案允许您将指定的大文件（例如音乐、图像和视频）存储在Git 仓库之外，并用Git 仓库内的元数据文件(.gitattributes) 替换它们。通过将大文件存储在Git 存储库之外，您可以减小Git 存储库本身的大小，加快Git 存储库的克隆速度，并防止由于存储库填满大文件而导致Git 性能下降。
Git LFS 目前得到了主流Git 服务提供商的支持，GitHub 和GitLab 都为其提供了内置支持。
但是，这些解决方案只是问题的临时解决方案，而不是在Git 存储库之外存储大文件的永久解决方案。这种方案需要对大文件进行单独维护，管理它们的同步和下载相对繁琐，并且相应的附加元属性文件存储在Git仓库中，管理也受到阻碍。
针对这些问题，部分克隆避免了维护两种存储和管理元属性文件的问题，从而从根本上优雅地解决了大文件的问题。
为了开始部分克隆，我们以Gitlab gitlab-com/www-gitlab-com 为例。本项目是一个gitlab在线文档仓库。仓库里有很多图片和3.5G的文件。使用部分克隆(–filter=blob:none) 进行部分克隆可以至少加快50% 的速度，并将下载的数据减少70%。
对于大型存储库，例如具有详细纹理和模型的视频游戏存储库，部分克隆带来的性能提升更为明显。
与传统的git 克隆相比，部分克隆提供了过滤器规范来控制下载Git 对象时要排除的内容。例如，在这种情况下，排除大型二进制文件。使用–no-checkout来比较显示效果。
上面，我们通过–no-checkout 选项来指定Git 不应检出默认分支。签出通常不需要从服务器检索数据，因为所有对象都是在克隆内本地下载的。当如上所述使用部分克隆时，有意配置为不下载所有内容，因此Git 在后续检出操作时必须检索本地不存在的所有对象。
如果您继续检查其他分支或提交，您将需要下载更多不存在的快照对象。
Git 会记住您在克隆存储库以检索更新并过滤掉大文件时提供的过滤器规范，并且仅在需要这些文件时才下载相应的快照对象。
git config 远程.origin.promisor
# 真相
git config remote.origin.partial 克隆过滤器
没有#blob:
当您提交更改时，只需提交二进制文件及其文件。无需安装或配置额外的工具，也无需将大文件与小文件区别对待。
部分克隆Git LFS 虽然非常易于使用，但它的缺点之一是它需要安装额外的工具。此外，部分克隆不需要其他工具。更新您的git 版本并了解现有git 命令的一些新选项。例如，git clone 的–filter 选项。您必须自行确定过滤器的最佳blob 大小或其他过滤器参数。
网络和存储使用过LFS 的同学可能知道，大文件的存储和传输方式与常规Git 对象不同。所有这些都被额外保存。最终的存储介质与普通文件（SSD）不同，下载会比较慢，需要考虑大存储。您的一些存储完全存储在Git 对象中，使您可以充分利用Git 的快速存储。例如，Gitlab 的存储可以支持多区域服务器，并允许您根据您的位置选择更近的区域服务，从而提高下载性能。
优化性能当您使用过滤器规范排除某些对象从Git 服务器下载时，Git 会检查每个对象并排除与过滤器规范匹配的对象。在最新版本的Git 2.25 中，过滤的性能优势并不明显，性能也没有得到优化。不过，Git 开源社区也在推动这方面的优化和改进。 Jeff King 提交了一个用于部分克隆blob 大小过滤的性能改进补丁。该补丁可以显着提升性能，将随Git 2.26 一起发布。服务器端GitLab 将于4 月22 日在12.10 版本中推出。
优化基于文件路径进行过滤的–filter:sparse 稀疏过滤器更为复杂，因为包含文件内容的blob 不包含文件路径信息，并且存储库目录结构存储在树对象中。
文件锁定和工具集成管理大型仓库还应该考虑客户端用户的文件锁定和工具集成。与纯文本源代码不同，通常无法解决不同版本的二进制文件之间的冲突。独占文件锁通常用于防止编辑二进制文件时发生冲突。这意味着一次只有一个人可以编辑文件，无论分支如何。如果无法解决冲突，允许在不同分支上并行创建文件的多个版本将报告错误。 Git 服务器已经具有基本的文件锁定支持，但这仅对纯文本和默认分支有效，尚无法与本地工具集成。
本地工具集成对于二进制文件工作流程非常重要，其中文件锁应自动传播到本地开发环境，从而消除设计人员在命令行使用Git 的需要。将文件锁快速传播到本地开发环境也很重要，以防止在文件锁发生之前浪费工作。
结论许多项目需要大文件。部分克隆仍然是一个实验性功能，但它是基于基本的git 解决方案，开源社区也在不断优化和改进该功能。用于优雅管理大型Git 文件的成熟、高性能解决方案即将推出。
本文和图片来自网络，不代表火豚游戏立场，如若侵权请联系我们删除：https://www.huotun.com/game/651000.html
