.net - 为什么不直接对引用进行源代码控制？

Question

我正在为我的组织建立一些新的源代码控制最佳实践，所以过去几天我一直沉浸在像 TreeSurgeon 这样的东西中。

我经常看到的一件事是，将您的引用包含在您的源代码控制树中是一种最佳做法，但是在单独的目录中(在树外科医生中为 lib/)而不是直接包含您的代码，因为它们自然出现在 ASP.NET 项目中。

我知道为什么直接在 bin 文件夹中对它们进行源代码控制不好的几个原因，但我想了解大局，包括在从源代码控制中提取代码后如何将这些引用恢复到 ASP.NET 项目中在新机器上。

提前致谢!

布赖恩

Answer 1

出于以下几个原因，您希望将外部依赖项放在单独的文件夹中:

您清楚地了解该特定外部依赖项中包含的内容

您可以添加与构建无关的内容，例如站点链接、文档、示例等，而不会污染您的项目

您可以在多个项目之间共享该依赖项

您不想将构建工件与源代码混合在一起，因为这会导致您/您的团队不清楚什么是您/您的团队拥有的，什么不是

您希望有明确的步骤在构建期间引入外部依赖项，以确保您可以控制最终包中的内容

如果它们在那里混合，分支源将创建您的依赖项的多个副本

一些菜鸟不小心 checkin 另一个版本的文件并弄乱您的外部依赖项的可能性较小，从而破坏您的项目

回答你的第二个问题:

我们通常在单独的文件夹中有一个外部依赖项的副本，但仍处于源代码控制之下。所有项目引用都使用相对路径指向该文件夹。因此，当人们使用新机器时，他们会获得一整套源代码以及准备构建产品的外部依赖项。

此外，我们的构建还有一个额外的步骤，可以在源树之外生成干净的放置文件夹。这是我们的部署副本，它包含最终产品工作所需的所有构建工件和所有源(如 .aspx)的副本。这迫使人们真正思考最终产品中需要包含什么。