Version control 如何在源代码管理中存储第三方库？
如何将项目中使用的第三方库存储在源代码管理中 什么时候在源代码管理中存储二进制文件 何时将代码存储在源代码管理中 你会把它们都储存起来吗？在什么情况下你会这样做Version control 如何在源代码管理中存储第三方库？,version-control,Version Control,如何将项目中使用的第三方库存储在源代码管理中 什么时候在源代码管理中存储二进制文件 何时将代码存储在源代码管理中 你会把它们都储存起来吗？在什么情况下你会这样做 （顺便说一句，我使用的是.NET，但这个问题并不重要）假设您使用的是.NET： 我在项目和源代码管理中创建一个“Libraries”文件夹，其中包含任何第三方程序集 然后，我的解决方案引用这些程序集，我的构建过程将该文件夹拉到构建服务器 从源代码管理中提取代码的任何人都应该能够编译代码，而不必查找引用和程序集。从概念上讲，您至少需要存储
（顺便说一句，我使用的是.NET，但这个问题并不重要）假设您使用的是.NET： 我在项目和源代码管理中创建一个“Libraries”文件夹，其中包含任何第三方程序集 然后，我的解决方案引用这些程序集，我的构建过程将该文件夹拉到构建服务器
从源代码管理中提取代码的任何人都应该能够编译代码，而不必查找引用和程序集。从概念上讲，您至少需要存储二进制文件（如果您使用C/C++，则需要存储头文件） 对于没有源代码的第三方库，这通常是唯一的方法
如果您有源代码，您可以选择存储源代码并在构建过程中构建第三方库。我的经验是创建一个“lib”文件夹，并将所有第三方二进制文件保存在其中。如果有，我将为这些第三方的源代码创建一个完全独立的树
有些地方可能会有所不同，如果您使用的是开源与零售第三方，使用开源解决方案，我倾向于只在项目中包含代码，而不签入二进制文件。您应该能够安装新的操作系统，从源代码控制中获取源代码，构建并运行。所以，是的，你应该把它们放在源代码管理中。这取决于它们有多大。当二进制文件或安装程序太大时，可能会对远程用户造成严重破坏。存储二进制文件和安装程序的好处在于，开发人员需要启动和运行的一切都在源代码管理中，并且版本正确。如果您有一个单独的安装位置，版本可能会混乱。所以，一般来说，我喜欢在源代码管理中存储小型或中型二进制文件，但我忽略了较大的二进制文件 编辑：哦，我叫我的“BinRef”：）
- 方法：a通常是一个好方法
- 何时（第三方）：为了最大限度地减少涉及的引用数量：您可以将这些库添加到单独的外部引用中（如Maven），但这意味着您需要为每个环境访问额外的引用（开发-集成-认证-预生产-生产）
- 何时（代码）：为了管理更改的复杂性，当您知道在进行新的开发时，将需要对运行到生产环境中的当前版本进行更新和修复时
- 为什么（同时存储）：原因：您可以在一个引用中管理完整的配置（所需元素列表），并在需要时随时随地查询：
- 开发（查询开发和执行代码所需的内容，包括编译/执行所需的第三方）
- 测试（集成、认证）：查询要更新测试工作区的exacts标记
- 生产：您可以准确地识别从一个来源进入生产的内容：您的SCM
如果其他项目依赖于您的产品，他们将根据存储在SCM中的打包版本构建自己的项目，而不是根据他们以某种方式重新编译的源代码 为什么这很重要？
因为最终，产品中运行的是产品的打包版本，而不是“重新编译的源代码”。因此，使用产品的最终目标形式进行所有测试，并在SCM中清楚地存储和标记，是非常重要的
提出了一个合理的观点 源代码管理被称为“源代码”管理，因为它应该控制源代码 虽然这在历史上可能是正确的，但当前的每个RCS都朝着SCM（）发展，SCM（）不仅控制源，还管理文档、程序和其他存储为计算机文件的信息的更改。
然后可以存储二进制文件（甚至使用二进制增量存储） 此外，还允许一些SCM提出S“C”M功能（如中所示）。
SCM（配置）不仅存储任何类型的“文件集”，而且还存储这些文件集之间的关系（也称为依赖关系），以便您查询一组文件，并每隔一次“拉”该文件集所依赖的交付（构建、部署或运行）您不需要在源代码管理存储库中存储第三方库。这些库（比如SDL、libcurl等）应该在web上始终可用。
只有两个种族标准：
- 确保在代码中明确说明应该编译库的哪个版本
- 确保该特定版本始终在web上可用
|-- src
|-- build
|-- lib
|- 3rdparty
|- internal