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

Question

多年来,我总是在\lib文件夹中存储二进制依赖项,并将其与项目的其余部分一起检查到源代码控制中.我发现我现在这样做了,所以我们有NuGet和NuGet包恢复.

我听说有些公司强制执行一项规则,即不能将二进制文件检入源代码控制.引用的理由包括:

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

Answer 1

我强烈建议你不要使用你描述的练习(禁止在源代码控制中使用二进制文件).实际上我称之为组织反模式.

最重要的一条规则是:

您应该能够在新机器上签出项目,并且必须开箱即用.

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

这样做的另一个非常有力的理由是避免版本问题 - 或者你知道吗？

针对上述内容的其他一些论点:

签入二进制文件极大地方便了构建自动化(并且不会妨碍它).通过这种方式,构建系统可以毫不费力地从VCS获得所需的一切.如果您以其他方式执行此操作,则始终涉及手动步骤.
只要您在Intranet中工作,性能考虑完全不相关,并且在使用基于Web的存储库时只考虑非常小的相关性(我想我们所讨论的仅仅是30-40 Megs,这不是真的对今天的带宽来说很重要).
根本没有功能丢失.这根本不是真的.
普通提交等速度较慢也是不正确的.这只是处理大型二进制文件时的情况,通常只发生一次.
而且,如果您签入了二进制依赖项,则至少需要一些控制权.如果你不这样做,你根本就没有.这肯定有更高的错误可能性......

@Win4ster只有当你的依赖项在你的控制之下时才是正确的。如果您需要打包名称中没有正确版本信息并且无法通过公共注册表获得的外部库，那么将它们置于版本控制中仍然是一种可行的方法。 (2认同)

Answer 2

我自己的经验法则是，生成的资产不应受到版本控制（无论它们是二进制的还是文本的）。有一些东西，如图像、音频/视频文件等，可能会被签入，并且有充分的理由。

至于具体几点。

您无法合并这些类型的文件，但它们通常只是被替换而不是分段合并。对于某些文件，可以使用自定义差异来区分它们，但一般来说，这是使用某种元数据（例如版本号）来完成的。
如果您有一个很大的文本文件，磁盘使用情况并不是反对版本控制的理由。同样在这里。这个想法是需要跟踪对此文件的更改。在最坏的情况下，可以将这些资产放在一个单独的存储库中（不会经常更改），然后使用某些 git 子模块将其包含在当前存储库中。
这是不正确的。对该特定文件的操作可能会较慢，但没关系。对于文本文件来说也是一样的。
我认为版本控制中的内容会增加存储库提供的便利性。经理。
这涉及到我的观点，即不应生成有问题的文件。如果未生成文件，则检出和构建是第一步。没有“下载二进制资产”阶段。