Git是跟踪代码库演变的绝佳选择，它使您可以与同事高效协作。当您要跟踪的库很大时会发生什么？在本文中，我将尝试为您提供一些正确处理不同类型大型仓库的想法和技巧。两种大型代码库仔细想想，仓库大量增长的原因大概有两个：项目积累了非常久远的历史（项目长期增长，积累包袱）。项目包括需要跟踪并与代码配对的大量二进制资产。两个都。因此，存储库在两个维度上增长：工作目录的大小——例如，最近的提交，以及整个累积历史的大小。有时第二种问题与存储库中保存的旧的过时二进制构建工件（工件）混合在一起，但这种问题更容易处理-如果它们很烦人，只需覆盖它们，见下文。上述两种情况所需的技术和解决方案是不同的——尽管有时是互补的——所以让我们分别处理它们。处理具有庞大历史的图书馆将图书馆视为庞大的门槛非常高——就像Linux内核的最新版本记录了超过1500万行代码，但人们仍然愿意完整地阅读它——由于监管/监管concerned原因，一些很老的项目还是需要原封不动的，克隆它们很痛苦（现在通过拆分linux仓库来说明，分成历史和最近的仓库，需要嫁接设置才能访问完整的历史).浅克隆是简单的解决方案为了更快、节省开发人员和系统时间以及节省磁盘空间，第一个解决方案是使用git进行浅克隆。浅克隆允许您仅克隆存储库的历史记录***。怎么做只需要使用--depth选项，比如：gitclone--depthdepthremote-url想象一下如果你的项目库已经积累了10年或者更多的历史记录——比如JIRA是11年我们迁移到git多年历史的图书馆-累积的时间节省非常可观。完整克隆的JIRA有677MB，如果包括工作目录，还有320+MB，总共有超过47,000次提交。通过浅克隆检查JIRE需要29.5秒，检查完整历史记录需要4分24秒。随着时间的推移和项目二元资产的增长，这个差距将按比例增长。在任何情况下，构建系统都会从这种技术（称为浅克隆）中受益匪浅。最近git改进了对浅克隆的支持。过去浅克隆就像是git世界的一个障碍，不支持一些操作。然而，最近的版本（1.9+）对此进行了显着改进，现在甚至可以在浅克隆存储库上正确使用拉取和推送操作。另一种解决方案是filter-branch（过滤器分支）。巨大的图书馆经常有很多错误的提交或无用的资源。为此，使用filter-branch是一个很好的解决方案。此命令可以根据预定义的模式过滤、排序、修改甚至跳过项目历史记录中的某些文件。它是git工具集中非常强大的工具。git存储库中已经有用于识别大对象的脚本，因此非常易于使用。使用filter-branch的例子：gitfilter-branch--tree-filter'rm-rf/path/to/spurious/asset/folder'HEADfilter-branch有个小缺点：一旦使用filter-branch，实际上整个项目历史已被重写，因此每次提交都会更改ID。这需要每个开发人员重新克隆更新的库。所以，如果你打算使用filter-branch来执行清理操作，你应该警告你的团队，计划一个短期的冻结来执行操作，然后通知大家重新克隆存储库。浅克隆的替代方案：仅克隆一个分支从2012年4月发布的git1.7.10开始，您可以通过仅克隆一个分支来限制历史记录的数量，如下所示：gitcloneURL--branchbranch_name--single-branch[文件夹]这个特殊的技巧对于长期运行的发行版的分支很有用，或者如果你有很多分支。如果您的分支很少，这种方法不会带来显着的效果。堆栈溢出参考。处理具有大量二进制资产的库第二类大型存储库包含具有大量二进制资产的代码。游戏团队处理巨大的3D模型，Web开发团队需要跟踪图形资产，而CAD团队可能需要操纵和跟踪二进制可交付成果的状态。所以就有各种软件团队在使用git的时候出现这样的问题。git在处理二进制资产方面并不是特别糟糕，但也不是特别好。默认情况下，git会以完全压缩的方式存储所有后续版本的二进制资产，如果您有大量二进制资产，这显然不是最佳解决方案。事情可以通过基本的调整来改进，比如运行垃圾收集gitgc，或者调整.gitattributes中的一些二进制类型以使用增量式提交。但是，请务必注意，您的项目中二进制资产的不同性质可能需要不同的方法。例如，这里有三件事要检查（感谢StefanSaasen的评论）：对于发生重大变化的二进制文件——意味着不仅元数据头发生变化——增量压缩可能无济于事，建议关闭这些文件的增量选项,为了避免不必要的增量压缩和重新打包对于上面的情况，就像有些文件不会被zlib很好地压缩一样，你使用core.compression0或者core.loosecompression0来关闭压缩；这是一个全局设置，会对其他压缩良好的非二进制文件产生负面影响。因此建议您将二进制资产放在单独的库中。请记住gitgc将“重复的”松散对象变成单个打包文件，除非以任何方式压缩文件不会使生成的打包文件明显不同。探索调整core.bigFileThreshold的效果。任何大于512MiB的东西都不会被增量压缩——如果.gitattributes没有设置——所以这样的调整值得一试。技巧1：稀疏签出一种更温和的管理二进制资产问题的方法是稀疏签出（自Git1.7.0起可用）。我们可以通过明确指定要填充的文件夹来保持工作目录的清洁。不幸的是，它不会影响本地存储库的整体大小，但如果您有一个巨大的文件夹树，这可能会有用。涉及哪些命令？这是一个示例（信用）：只克隆所有存储库一次：:gitclone
