我的一个项目有一个文件夹，里面有十万个微小的 MP3 文件（一些口语）。
在 repo 中，到目前为止我只提交了项目的代码部分，而我还在为如何处理资产而苦恼。
当然，git 是用于跟踪基于文本的文件，但是当它们成为项目的一部分时，我们都会跟踪一些其他资产。
我在两个选项之间犹豫不决，希望得到一些意见。
追踪所有事物。
在此选项下，git 将跟踪 100K 资产文件。好处是，一旦它们上传到 GitHub，将很少发生更改（这里或那里重命名文件）。
我担心的是 git 将如何处理后续每次提交的资产。每次提交时，git 是否会重新计算所有资产文件的哈希值以将它们与上次提交进行比较？如果是这样，每次提交都会花费很长时间。
不跟踪资产，但向发布中添加大型存档文件
在这个选项下，git 不会跟踪 mp3，但我将创建 GitHub 版本，我将在其中上传7z资产文件二进制文件发行版的部分。我看到的缺点是，如果我重命名单个 MP3 文件，则下一个发行版将是材料的重复，这是浪费。
答案1
现在chromium.git有 315k 个文件，gentoo.git 有 90k 个文件，linux.git有 70k 个文件。因此这些文件数量并不罕见，Git 已经针对它进行了优化。
主要是，Git 签出（工作目录）的“.git/index”存储了有关工作树中文件的更多信息 - 它跟踪文件的 inode 编号、inode 更改时间和文件修改时间。如果所有这些参数都相同，则“git add”将假定实际文件也相同。
（是的，缓慢的部分实际上是“git add”，因为这是完成文件扫描和导入的地方 - 后续的“git commit”只是转储已经收集的索引信息。）
如果您的文件组织在深度嵌套的目录中，您可能会发现这些 Git 配置选项很有用（尽管它们只影响本地签出而不影响实际的历史数据库）：index.version=4或feature.manyFiles=true。
Git 并不关心它是否存储的是二进制文件。MP3 文件的实际问题是它们已经压缩，这意味着一个文件与另一个文件有很大不同，因此 Git 的常规存储优化会遇到一些困难。但是，如果文件很少更改，这应该不会造成任何问题。
如果文件很小而且很多，我认为你从 Git LFS 或 git-annex 中获益不多——它实际上可能会让事情慢点因为每个文件都需要通过单独的请求下载到服务器。