我有一个视觉工作室解决方案，有一些（约20个）项目。用于此解决方案的源代码控制是git。
这些项目是围绕现有的应用程序服务器（闭源，仅二进制）构建的。应用程序服务器包含大约300个文件/ 140 MB。应用程序服务器的版本可以每年更改6次（如果需要新功能/错误修正） 开发人员需要此应用程序服务器来测试（集成测试）开发。
这些项目中的大多数都引用了此应用程序服务器的某些程序集（即，为了建立连接）。大约有15个文件，我们为此创建由我们自己托管的NuGet包。
某些项目可能会引用官方的金块包。
某些项目可能引用了位于“lib”文件夹中的3rth聚会程序集，并且是解决方案的一部分。 lib文件夹也是git存储库的一部分。
我们应该在何处以及如何放置应用程序服务器文件？
放入lib文件夹旁边的app文件夹并将其添加到git存储库。
将robocopy脚本放入后期构建事件中，并在从网络共享或Internet成功构建后复制应用服务器。
我们应该使用上述版本之一吗？ 是否有其他可能性/最佳实践可以解决这种情况？
答案 0 :(得分：2)
您应该使用工件存储库。这正是工件存储库的用途：“源控制”专门用于二进制工件。
我没有使用NuGet工件的经验，但我从JFrog看到artifactory supports NuGet。有一个关于这个here on SO的优点答案。
虽然我通常更喜欢nexus而不是神器，但在这个问题上接受的答案在这种情况下为神器提供了令人信服的论据。
答案 1 :(得分：1)
像@PaulHicks这样的工件库建议听起来很理想。
然而，如果你没有时间，基础设施或技术来采取这种方法（开始），我谦卑地提出我认为你有点过分思考这个140 MB - 你有点夸大你的缺点你注意...
缺点：git存储库中的许多二进制文件。将导致巨大的git存储库。
......并且应该强烈考虑使用版本1。
如果你已经在源代码库中维护了Lib引用的二进制文件，那么额外的140 MB对我来说似乎不是什么大问题 - 特别是考虑到你注意到的巨大好处：
Pro：开发人员只需git checkout即可启动应用服务器。开发人员可以脱机工作。
版本1的另一个好处（无可否认，更新app-server软件包以使用工件存储库方法）可以清楚地了解解决方案所使用的应用服务器版本。
答案 2 :(得分：1)
建议的版本1 是可行的，这是我想要的，稍作修改。我将 app 文件夹作为独立的repo管理，因此作为git submodule。
在二进制文件的回购中进行标记和版本控制具有将所有内容准备好放在一个地方的优点，以及为了测试目的而切换到另一个版本的二进制文件的自由和轻松。
那就是说，如果我是一名开发人员，我可能会忽略自己对子模块的建议并按如下方式进行管理：
这样我可以享受两个世界中最好的，代码和二进制文件分别进行版本化，但我随时准备好了，因为两个repos的组合允许我脱机工作，必要时拉动和推动。
总结一下，我认为你应该只提供两个存储库。一个用于二进制文件，一个用于源代码，虽然你可以提供建议的“howto”蓝图，但你也应该让开发人员自由地用他们的聪明才智给你一个惊喜。
<子>
1 如果需要多个克隆或文件大小失控，我会使用git annex 2 How does git handle symbolic links?