我正在开发一个LateX包 (http://www.openlilylib.org/lilyglyphs)，其中包含许多小的PDF文件。目前只有几十个，但随着包和用户基础的增长，可能会有数百个（但不太可能超过1000个）。
PDF文件通常只有几KB大小，但我不知道是否要在Git仓库中跟踪它们。这些文件随时可能会更改，但可能不会太频繁。
通常不建议跟踪无法差异化的二进制文件，但我也读到过对于较小的文件和较小的总体积，这并不重要。我认为最终PDF将总计不超过几MB。
该包将可通过下载或Git仓库获取，我更喜欢后者，因为使用该包自然会导致贡献...
当前，在克隆Git仓库时，必须使用Python和LilyPond符号软件重新构建pdfs，因此风险相当高-这就是为什么我希望直接在repo中拥有pdfs的原因。
任何想法？
编辑以回应答案/评论： pdf文件是从存储库中的源代码生成的，这就是为什么我不愿意在Git中跟踪它们的原因。
但是：
PDF文件通常只有几KB大小，但我不知道是否要在Git仓库中跟踪它们。这些文件随时可能会更改，但可能不会太频繁。
通常不建议跟踪无法差异化的二进制文件，但我也读到过对于较小的文件和较小的总体积，这并不重要。我认为最终PDF将总计不超过几MB。
该包将可通过下载或Git仓库获取，我更喜欢后者，因为使用该包自然会导致贡献...
当前，在克隆Git仓库时，必须使用Python和LilyPond符号软件重新构建pdfs，因此风险相当高-这就是为什么我希望直接在repo中拥有pdfs的原因。
任何想法？
编辑以回应答案/评论： pdf文件是从存储库中的源代码生成的，这就是为什么我不愿意在Git中跟踪它们的原因。
但是：
- PDF文件对使用包来说是必需的，所以用户需要拥有它们
- 要生成pdfs，需要Python和LilyPond，而且两者都不是使用该软件包所必需的。因此，要求某人安装两个程序才能安装我的包可能是一个太大的负担。
我不认为需要运行安装脚本的人会有问题，但软件依赖性可能太高？ - 目前，生成pdfs的时间合理，因为只有几十个文件。但是随着文件数量的增加，这个时间可能变得不可接受。
PDF文件在更新/修正时会发生变化。这种情况不会经常发生，我认为通过跟踪源代码已经可以解决此问题。但是每当有新版本的LilyPond可用时（可能每两到四周），PDF也会发生变化。因此，尽管源代码保持不变，PDF将定期更改-这是不适合使用Git进行跟踪的明确指标。
另一方面，我们讨论的是可能只有几百个几KB的文件，因此我不知道是否值得担心这个问题。