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

问题描述

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

I am developing a LateX package (http://www.openlilylib.org/lilyglyphs) which contains a number of small PDF files. Currently there are only a few dozens of them but as the package and its user base grows there will probably hundreds of them (but unlikely more than 1000).

PDF的大小通常只有几KB，但我不知道是否要在Git存储库中对其进行跟踪.这些文件随时可能更改，但可能不会经常更改.
通常会告诉人们不要跟踪无法进行比较的二进制文件，但是我也已经读到，对于较小的文件和较小的总体积来说，这并不重要.我认为最终这些PDF总计不超过几MB.

The PDFs are typically only a few KB in size, but I don't know whether to track them in the Git repository. The files are subject to change at any time, but probably not too often.
Usually one is told not to track binary files which can't be diffed, but I also have read that this doesn't really matter with smaller files and a smaller overall volume. I think in the end the PDFs will sum up to not more than a few MB in total.

该软件包可以通过下载获得，也可以通过我喜欢的Git存储库获得，因为使用软件包自然会导致贡献 ...
当前，在克隆Git存储库时，必须使用Python和LilyPond表示法软件重建pdf，因此赌注很高-这就是为什么我希望将pdf直接存储在回购中.

The package will be available as a download or through the Git repository which I prefer because using the package quite naturally leads to contributing ...
Currently when cloning the Git repository one has to rebuild the pdfs using Python and the LilyPond notation software so the stakes are rather high - which is why I would like to have the pdfs directly in the repo.

有什么想法吗?

编辑答案/评论:

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

The pdf files are generated from the sources in the repository, which is why I'm reluctant to track them in Git.
But:

• 使用该软件包必须使用pdf文件，以便用户需要它们
• 要生成pdf文件，需要Python和LilyPond，并且使用包都不需要 .因此，我觉得要求某人安装两个程序来安装我的软件包实在是一个太大的负担.
  我看不到需要决定克隆Git存储库以运行安装脚本的问题，但是软件依赖性可能太高了吗?
• 当前生成pdf的时间很短，因为只有几十个.但是随着文件数量的增加，这次可能会变得不可接受.

• The pdfs are necessary to use the package so the user needs to have them
• To generate the pdfs one needs Python as well as LilyPond, and both of them are not necessary to use the package. So I feel it is a too big burden to require someone to install two programs just to install my package.
  I don't see a problem requiring someone who decides to clone a Git repo to run an install script, but the software dependencies are maybe too high?
• Currently generating the pdfs finishes in reasonable time because there are only a few dozens. But with a growing number of files this time could become inacceptable.

PDF文件在更新/更正后会更改.这种情况不会经常发生，我认为可以通过跟踪源代码来解决.但是，只要有新版本的LilyPond(可能每两到四周一次)，PDF就会更改.因此，在源保持不变的情况下，pdf将会定期更改-这是明确的指标，表明无法使用Git对其进行跟踪.
另一方面，我们正在谈论(可能是)几百个文件，每个文件只有几KB，所以我根本不知道是否值得为此问题打扰.

The pdf files change when they are updated/corrected. This won't happen often, and I think this is covered by tracking the source code. But the pdfs will also change whenever there is a new version of LilyPond available, which may be every two to four weeks. So while the source remains the same the pdfs will change regularely - which is a clear indicator against tracking them with Git.
On the other hand we are talking about (possibly) a few hundred files of a few KB each, so I don't know if it's worth bothering about the issue at all.

推荐答案

如果文档未更改，则没有理由在git中跟踪其更改.没有修订，不需要修订控制.

If the documents don't change, there is no reason to track their changes in git. No revisions, no need for revision control.

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

But if they do change over time, and someone may need to consult the old document versions for any reason, consider these questions:

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

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

If the answers to these questions are yes, then they may be good candidates for version control under git.

这篇关于何时应在Git存储库中跟踪pdf文件，何时不跟踪的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！