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

别人在做什么？

解决方案

回答

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

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

回答

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

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

回答

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

回答

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

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

回答

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

回答

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

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

回答

我通常将它们存储在存储库中，但是我对我们希望减小尺寸的想法表示同情。

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

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

回答

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

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

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

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

回答

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

回答

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

回答

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

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

回答

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

• 为什么将未更改的文件存储到专门设计用于管理已更改文件的系统中？
• 大大加快了退房时间
• 每次看到在源代码控制下存储的" something.jar"时，我都会问"它是哪个版本？"

回答

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

回答

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

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

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

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

回答

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

回答

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