多年来，我一直在\lib文件夹中存储二进制依赖项，并将其与项目的其余部分一起检查到源代码控制中。我发现我这样做的次数少了，因为我们现在有NuGet和NuGet Package Restore。
我听说有些公司强制执行一项规则，即不能将二进制文件检入源代码管理中。引用的理由包括：
对于绝大多数使用源代码控制的项目，是否存在支持或反对此做法的客观论据？
答案 0 :(得分：8)
我强烈建议您不要使用您描述的练习（禁止在源代码控制中使用二进制文件）。实际上我称之为组织反模式。
最重要的一条规则是：
您应该能够在新机器上签出项目，并且必须开箱即用。
如果可以通过NuGet完成，那么就好了。如果没有，请检查二进制文件。如果存在任何法律/许可证问题，那么您的仓库中至少应包含一个包含所有必需信息的文本文件（名为how_to_compile.txt或类似文件）。
这样做的另一个非常有力的理由是避免版本问题 - 或者你知道吗
针对上述内容的其他一些论点：
答案 1 :(得分：2)
事情取决于工作流程和使用的VCS。
使用基于组件的工作流与SVN，您可以检入组件的包含和库。通过这个libs和include为其他组件创建接口。这些只导入libs并包括使用svn：externals而根本不导入组件的源代码。这会强制实现干净的界面以及不同组件之间的严格分离：组件是一个黑盒子，只能在界面中指定使用。内部结构对其他人来说是不可见的。使用二进制文件可以减少编译时间，并且可以减少机器上编译所需的工具数量，因为在使用它时，创建组件所需的专用工具不需要存在。
但是，使用分布式VCS的东西不会以这种方式工作。 DVCS依赖于克隆整个存储库。签入二进制文件时，存储库的大小将快速增长，这将花费太长时间。虽然拥有100GB的SVN存储库不是一个问题，因为结账只处理一个较小几个数量级的修订版，但是这个大小的Git / Mercurial / Bazaar存储库会使它无法使用，因为克隆需要很长时间。
因此，检查二进制文件是否是个好主意取决于您的工作流程，还取决于所使用的工具。
答案 2 :(得分：2)
我自己的经验法则是生成的资产不应受版本控制（无论它们是二进制还是文本）。有几个东西，如图像，音频/视频文件等可能会被检查，并且有充分的理由。
具体要点。
您无法合并这些类型的文件，但它们通常只是替换而不是分段合并。对于使用自定义不同的某些文件，可能会对它们进行区分，但一般来说，这是使用某种类型的元数据（如版本号）完成的。
如果您有一个大文本文件，则磁盘使用不是版本控制的参数。同样在这里。我们的想法是需要跟踪对此文件的更改。在最坏的情况下，可以将这些资产放在一个单独的存储库中（不会经常更改），然后使用git子模块将其包含在当前存储库中。
这根本不是真的。对该特定文件的操作可能会较慢，但这没关系。对于文本文件也是如此。
我认为在版本控制中使用可以增加回购提供的便利性。管理器。
这触及了我的观点，即不应该生成相关文件。如果未生成文件，则checkout和build是一步。没有＆＃34;下载二进制资产＆＃34;阶段。
答案 3 :(得分：0)
几乎所有现代编程平台都有自己的包管理器。这意味着，共享二进制文件最好打包成包并使用包管理系统发布。即使是没有相应官方包的 3rd 方二进制文件和资源，在大多数情况下，您也可以将其包装到您自己的包中，将其存储在您的私有包存储库中，并在您自己的 CI/CD 系统中使用它来构建您的产品。 因此，对于 source 代码使用 source 代码存储库，对于二进制文件和 3rd 方依赖项使用包管理系统。关注点分离。