我正在开发一个包含许多小 PDF 文件的 LateX 包 ( http://www.openlilylib.org/lilyglyphs)。目前只有几十个，但随着软件包及其用户群的增长，可能会有数百个(但不太可能超过 1000 个)。
PDF 的大小通常只有几 KB，但我不知道是否要在 Git 存储库中跟踪它们。这些文件随时可能更改，但可能不会太频繁。
通常有人被告知不要跟踪无法区分的二进制文件，但我也读到这对于较小的文件和较小的总体积并不重要。我认为最终 PDF 的总和不会超过几 MB。
该软件包可以通过下载或通过我更喜欢的 Git 存储库获得，因为使用该软件包很自然地导致贡献 ...
目前，当克隆 Git 存储库时，必须使用 Python 和 LilyPond 符号软件重建 pdf，因此风险相当高 - 这就是为什么我希望直接在存储库中拥有 pdf。
有什么想法吗？
针对答案/评论进行编辑:
pdf 文件是从存储库中的源代码生成的，这就是我不愿意在 Git 中跟踪它们的原因。
- pdf 是使用包所必需的，因此用户需要拥有它们
- 要生成 pdf，需要 Python 和 LilyPond，而它们不是使用该包所必需的。所以我觉得要求别人安装两个程序只是为了安装我的包是一个太大的负担。
我没有看到需要决定克隆 Git 存储库的人运行安装脚本的问题，但软件依赖性可能太高了？ - 目前生成的 pdf 文件在合理的时间内完成，因为只有几十个。但是随着文件数量的增加，这一次可能会变得 Not Acceptable 。
pdf 文件在更新/更正时会发生变化。这种情况不会经常发生，我认为这可以通过跟踪源代码来解决。但是只要有新版本的 LilyPond 可用，pdf 也会更改，这可能每两到四个星期一次。因此，虽然来源保持不变，但 pdf 文件会定期更改 - 这是反对使用 Git 跟踪它们的明确指标。
另一方面，我们正在谈论(可能)几百个文件，每个文件只有几 KB，所以我根本不知道是否值得为这个问题烦恼。
最佳答案
如果文档没有变化，就没有理由在 git 中跟踪它们的变化。没有修订，不需要修订控制。
但是如果它们随着时间的推移确实发生了变化，并且有人可能出于任何原因需要查阅旧文档版本，请考虑以下问题:
- 重新创建旧版本的文档是否不可能或不切实际？
- 版本控制之外的任何基础数据是否发生了变化，或者是否仍处于相同状态？
- 文档中的数据是否与源代码发布相关联？
如果这些问题的答案是肯定的，那么它们可能是 git 下版本控制的良好候选者。
关于git - 何时应在 Git 存储库中跟踪 pdf 文件，何时不应，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17772048/