何时应该在Git存储库中跟踪pdf文件,何时不跟踪

uli*_*973 13 git binaryfiles

我正在开发一个包含许多小PDF文件的LateX软件包(http://www.openlilylib.org/lilyglyphs).目前只有几十个,但随着软件包及其用户群的增长,可能会有数百个(但不可能超过1000个).

PDF通常只有几KB大小,但我不知道是否在Git存储库中跟踪它们.这些文件可能随时更改,但可能不会经常更改.
通常会告诉一个人不要跟踪无法区分的二进制文件,但我也已经读过,这对于较小的文件和较小的整体音量并不重要.我认为最终PDF总数不会超过几MB.

该软件包将作为下载或通过我喜欢的Git存储库提供,因为使用该软件包很自然地导致贡献 ...
当前克隆Git存储库时,必须使用Python和LilyPond表示法软件重建pdf所以赌注相当高 - 这就是为什么我想在回购中直接使用pdf.

有什么想法吗?


编辑回答/评论:

pdf文件从存储库中的源生成的,这就是我不愿意在Git中跟踪它们的原因.
但:

  • pdfs是使用包所必需的,因此用户需要使用它们
  • 要生成pdfs,需要Python和LilyPond,并且它们都不需要使用该包.因此,我觉得要求某人安装两个程序只是为了安装我的软件包是一个太大的负担.
    我没有看到需要某人决定克隆Git仓库来运行安装脚本的问题,但软件依赖性可能太高了?
  • 目前生成pdfs在合理的时间内完成,因为只有几十个.但随着越来越多的文件,这次可能变得无法接受.

更新/更正时,pdf文件会发生变化.这不会经常发生,我认为跟踪源代码可以解决这个问题.但是,每当有新版本的LilyPond可用时,pdf也会发生变化,可能每两到四周一次.因此虽然源代码保持不变,但pdf将会正常更改 - 这是用Git跟踪它们的明显指标.
另一方面,我们正在讨论(可能)几百个文件,每个文件几KB,所以我不知道是否值得为这个问题烦恼.

pla*_*rms 6

如果文档没有更改,则没有理由在git中跟踪其更改。没有修订,无需修订控制。

但是,如果它们确实随着时间而改变,并且由于某些原因可能有人需要查阅旧文档版本,请考虑以下问题:

  1. 重新创建旧版本的文档是不可能还是不切实际的?
  2. 版本控制之外是否存在任何已更改的基础数据,还是仍处于相同状态?
  3. 文档中的数据是否与源代码发布绑定在一起?

如果这些问题的答案是肯定的,那么它们可能是git下版本控制的不错选择。