17

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

PDF 通常只有几 KB 大小，但我不知道是否在 Git 存储库中跟踪它们。这些文件随时可能更改，但可能不会太频繁。
通常有人被告知不要跟踪无法区分的二进制文件，但我也读到这对于较小的文件和较小的总体积并不重要。我认为最终 PDF 的总和不会超过几 MB。

该软件包将可作为下载或通过我更喜欢的 Git 存储库提供，因为使用该软件包很自然地会导致贡献......
目前，当克隆 Git 存储库时，必须使用 Python 和 LilyPond 符号软件重建 pdf，所以风险相当高 - 这就是为什么我想将 pdf 直接放在 repo 中。

有什么想法吗？

编辑以回应答案/评论：

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

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

pdf 文件在更新/更正时会发生变化。这不会经常发生，我认为这可以通过跟踪源代码来解决。但是，只要有新版本的 LilyPond 可用，pdf 也会发生变化，可能每两到四个星期。因此，虽然来源保持不变，但 pdf 会定期更改 - 这是一个明确的指标，反对使用 Git 跟踪它们。
另一方面，我们正在谈论（可能）几百个文件，每个文件只有几 KB，所以我不知道是否值得为这个问题烦恼。

4

3 回答 3

8

如果文档没有更改，则没有理由在 git 中跟踪它们的更改。无需修订，无需修订控制。

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

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

如果这些问题的答案是肯定的，那么它们可能是 git 下版本控制的良好候选者。

于 2013-07-21T15:20:37.843 回答
2

问题是：您是想将 git 专门用于源代码管理/跟踪/同步，还是也想将其用于分发？对于小型项目，它简化了以这种方式进行的操作，对于大型项目，它会使 repo 膨胀。

于 2013-07-22T08:07:15.323 回答
2

我知道这是一篇旧帖子，但我在搜索时发现了它，因此其他人也可以这样做。这是我找到的一些选项

正如已经指出的那样，很大程度上取决于这些源文件是否会随着时间而改变。

如果它们不更改（或不经常更改），您可以选择将它们的副本保存在您控制的服务器或云存储选项上，并让您的安装脚本下载它们而不是生成它们。

这可能取决于安装了 wget 或 curl 的用户，但大多数人都安装了，如果他们没有安装，您总是可以提示用户手动下载它们。

如果 PDF 确实经常随源更改，您可以查看GIT LFS。我自己从未使用过它，但见过它使用过。

于 2017-05-14T10:41:05.260 回答