git - 在源代码管理中存储二进制依赖项是一种好习惯吗？

Question

多年来，我一直将二进制依赖项存储在 \lib 文件夹中，并将其与项目的其余部分一起检查到源代码管理中。现在我们有了 NuGet 和 NuGet 包恢复，我发现我很少这样做。

我听说有些公司强制执行任何二进制文件都不能 checkin 源代码管理的规则。列举的原因包括:

1. 大多数 VCS 不能很好地处理二进制文件 - 比较和 merge 没有得到很好的支持
2. 磁盘使用量增加
3. 提交和更新速度较慢
4. 将失去存储库管理器提供的开箱即用的额外功能、控制和易用性
5. 它鼓励进一步的不良做法；理想情况下，项目应该寻求完全自动化他们的构建，检查版本控制通常是一个手动步骤

对于绝大多数使用源代码控制的项目，是否存在支持或反对这种做法的客观论据？

Answer 1

我强烈建议您不要使用您描述的做法(在源代码管理中禁止二进制文件的做法)。实际上，我将其称为组织反模式。

最重要的一条规则是:

您应该能够在新机器上 checkout 项目，并且它必须开箱即用。

如果这可以通过 NuGet 完成，那么很好。如果没有，请检查二进制文件。如果存在任何法律/许可问题，那么您的存储库中至少应该有一个包含所有必需信息的文本文件(名为 how_to_compile.txt 或类似文件)。

这样做的另一个非常重要的理由是避免版本控制问题——或者你知道吗

• 某个库的具体版本在几年前运行，并且
• 如果它真的是项目中使用的实际版本，并且
• 可能是最重要的:您知道如何获得准确的版本吗？

反对上述的一些其他论点:

• checkin 二进制文件极大地促进了构建自动化(但并不妨碍它)。这样构建系统就可以毫不费力地从 VCS 获得它需要的一切。如果您以其他方式进行操作，则始终需要手动操作。
• 只要您在 Intranet 中工作，性能方面的考虑就完全无关紧要，而在使用基于 Web 的存储库时只有非常小的相关性(我想我们谈论的不超过，比方说，30-40 兆，这对于今天的带宽来说并不是什么大问题)。
• 没有任何功能丢失。那根本不是真的。
• 正常提交等速度较慢也是不正确的。只有在处理大型二进制文件本身时才会出现这种情况，这种情况通常只会发生一次。
• 而且，如果您检查了二进制依赖项，您至少有一些 控制权。如果你不这样做，你就什么都没有。这肯定有更高的错误可能性......