在源代码管理中存储第三方库

Storing third-party libraries in source control

应否将应用程序依赖的库存储在源代码管理中？我的一部分说应该，另一部分说不。添加一个20mb的库使整个应用程序相形见feel是错误的，这仅仅是因为您依赖于它的几个功能(尽管相当繁重)。您应该只存储jar / dll还是项目的分布式zip / tar？

别人在做什么？

存储从现在起10年后构建项目所需的一切。我存储所有库的整个zip发行版，以防万一

编辑2017年：
这个答案年龄不好：-)。如果您仍在使用诸如ant或make之类的旧内容，上述内容仍然适用。如果您使用诸如maven或graddle之类的更现代的东西(例如，.net上的Nuget)进行依赖管理，则除了版本控制服务器之外，您还应该运行依赖管理服务器。只要两者都有良好的备份，并且依赖性管理服务器不会删除旧的依赖性，就可以了。有关依赖关系管理服务器的示例，请参见例如Sonatype Nexus或JFrog Artifcatory。

除了在您的存储库中拥有第三方库之外，值得这样做的方式还可以使其轻松跟踪和合并将来对库的更新(例如，安全修复程序等)。如果您使用Subversion，则使用适当的供应商分支是值得的。

如果您知道在修改第三方代码之前会是一个阴冷的日子，那么(如@Matt Sheppard所说)外部接口是有道理的，它为您带来了额外的好处，即可以很容易地切换到如果需要安全更新或必备的新功能，则应使用该库的最新版本。

此外，在更新代码库时，如果需要，可以省去长时间的缓慢加载过程，从而可以跳过外部。

@Stu Thompson提到在源代码管理中存储文档等。在较大的项目中，我已经将整个"客户"文件夹存储在源代码管理中，包括发票/账单/会议记录/技术规格等。整个射击比赛。尽管，请记住将这些内容存储在一个单独的存储库中，该存储库将由您提供给以下人员：其他开发人员；客户端;您的"浏览器源代码视图" ...咳嗽... :)

不要存储库；它们并不是严格意义上的项目，在您的版本控制系统中毫无用处。但是，一定要使用Maven(或针对蚂蚁构建的Ivy)来跟踪项目使用的外部库的版本。您应该在组织中运行仓库的镜像(已备份)，以确保始终将依赖项置于您的控制之下。这应该使您两全其美；项目外部的外部jar，但仍然可靠且可集中访问。

我们将库存储在源代码管理中，因为我们希望能够通过简单地签出源代码并运行构建脚本来构建项目。如果您无法获取最新信息并一步一步构建，那么以后您只会遇到问题。

永远不要将您的第三方二进制文件存储在源代码管理中。源代码控制系统是支持并发文件共享，并行工作，合并工作和更改历史记录的平台。源代码管理不是二进制文件的FTP站点。第三方程序集不是源代码；每个SDLC可能会更改两次。能够清理工作空间，从源代码管理中拉取所有内容并进行构建的愿望并不意味着第三方程序集需要卡在源代码管理中。您可以使用构建脚本来控制从分发服务器提取第三者程序集。如果您担心控制应用程序的哪个分支/版本使用特定的第三方组件，那么也可以通过构建脚本来控制它。人们已经提到Maven for Java，并且您可以使用MSBuild for .Net进行类似的操作。

我通常将它们存储在存储库中，但是我很同情您希望减小尺寸的愿望。

如果您不将它们存储在存储库中，则绝对需要以某种方式对其进行存档和版本控制，并且您的构建系统需要知道如何获取它们。 Java世界中的许多人似乎都在使用Maven自动获取依赖项，但是我没有用过，所以我不能真正推荐或反对它。

一个好的选择可能是保留第三方系统的独立存储库。如果您使用Subversion，则可以使用Subversion的外部支持自动从另一个存储库中签出库。否则，我建议保留一个内部匿名FTP(或类似的)服务器，您的构建系统可以从中自动获取需求。显然，您将要确保保留所有旧版本的库，并将所有内容与存储库一起备份。

我所拥有的是一个内部Maven式的存储库，其中存储了所有第三方库(不仅是库，而且包括文档，Javadoc和所有内容的它们各自的源代码分发)。原因如下：

为什么将未更改的文件存储到专门设计用于管理已更改文件的系统中？

大大加快了退房时间

每次看到在源代码控制下存储的" something.jar"时，我都会问"它是哪个版本？"

我的首选是将第三方库存储在依赖项存储库(例如，带有Maven的Artifactory)中，而不是将其保留在Subversion中。

由于第三方库没有像源代码那样进行管理或版本控制，因此将它们混合在一起没有任何意义。远程开发人员还欣赏不必从慢速WPN链接下载大型库，因为他们可以从任意数量的公共存储库中更轻松地获取大型库。

我将除JDK和IDE之外的所有内容都放入了源代码管理中。

托尼的哲学是正确的。不要忘记数据库创建脚本和数据结构更新脚本。在Wiki出现之前，我什至曾经将文档存储在源代码管理中。

在以前的雇主中，我们将在源代码管理中构建应用程序所需的一切都存储了。旋转新的构建机器是与源代码控制同步并安装必要的软件的问题。

就我个人而言，我的项目中有一个依赖文件夹，并在其中存储引用的库。

当我从事多个不同的项目时，常常发现相互依赖的部分需要相同版本的库，因此我发现这样做使工作变得更轻松，这意味着更新到给定库的最新版本并不总是可行的。

在每个项目的编译时都使用所有依赖关系意味着在事情进展的几年后，我仍然可以构建项目的任何部分，而不必担心会破坏其他部分。升级到新版本的库只是替换文件并重建相关组件的情况，如果需要的话，管理起来并不难。

话虽如此，我发现我所引用的大多数库都是相对较小的，大约只有几百kb，很少有更大的库，这对我来说，仅将它们放在源代码控制中就没有什么问题了。

使用git子项目，并从第3方库的主git存储库中进行引用，或者(如果没有)则为每个所需的库创建一个新的git存储库。没有任何理由将您限制在一个git存储库中，并且我不建议您将别人的项目仅用作自己的目录。

存储库！该存储库应该是随时构建项目所需要的快照。由于项目需要不同版本的外部库，因此您将需要更新/签入这些库的较新版本。这样，如果您必须修补较旧的发行版等，则将能够获得与旧快照一起使用的所有正确版本。

将第三方库存储在源代码管理中，以便在将代码签出到新的开发环境时可以使用它们。您可能在生成脚本中包含的任何"包含"或生成命令也应引用这些"本地"副本。

在确保始终可以使用您依赖的第三方代码或库的同时，这还意味着新开发人员加入团队后，代码(几乎)可以在新的PC或用户帐户上构建。

您必须存储构建项目所需的一切。
此外，您的代码的不同版本可能对第三方有不同的依赖性。
您需要将代码及其第三方依赖项分支到维护版本中...

就我个人而言，我已经做过并且到目前为止一直很满意的结果是将库存储在一个单独的存储库中，然后通过使用Subversion svn：externals功能链接到我在其他存储库中需要的每个库。这很好用，因为我可以将大多数库(主要是托管的.NET程序集)的版本副本保留在源代码控制中，而又不会增加我们主要源代码存储库的大小。以这种方式将程序集存储在资源库中，可以使构建服务器无需安装即可进行构建。我要说的是，在没有安装Visual Studio的情况下使构建成功是一件很麻烦的事，但是现在我们可以正常工作了，对此我们感到满意。

请注意，我们目前不使用许多商业第三方控制套件或类似的东西，因此我们没有遇到许可问题，在这些许可中可能需要在构建服务器上实际安装SDK，但我可以看到在哪里很容易成为问题。不幸的是，我没有针对此的解决方案，当我初次遇到它时会计划解决该问题。

存储构建项目所需的一切，因此您无需执行任何操作即可检出并进行构建。

(而且，作为经历过痛苦的人-请保留安装控件并在开发平台上工作所需的所有内容的副本。我曾经有一个可以构建的项目-但没有安装文件和reg键，则无法不会对第三方控件的布局进行任何更改。这很有趣。