我们使用Visual Studio 2010（在C＃中）进行开发，并在不久前从SVN迁移到GIT。现在我们尝试将我们的存储库（相当大的~~30,000个文件）拆分到许多git存储库 - 每个解决方案一个。 这些解决方案共享一些项目，主要是我们在内部开发的库，并希望从所有解决方案中添加。
新的存储库具有平面布局。每个项目的一个子目录（共享项目是子模块）。 在旧的大型仓库中，项目采用树形结构。
子模块中的外部引用会出现问题。在新的repos中，引用项目的路径可能是＆＃34; ...... libs \ someproject＆＃34;，而在新布局中，正确的路径将是＆＃34; .. \ someproject＆＃34 ;
我们已经有过一些关于此的编辑战争，并且不再热衷于此。
我能想到的半生不熟的解决方案：
使用＆＃34;参考路径＆＃34;在... csproj.user中并从版本控制中排除此文件（必须为每个开发人员重做并在每次清理后进行重做）
为每种情况使用分支，并尝试教导每个人在哪里＆＃34;真实＆＃34;承诺应该去哪里＆＃34;环境变化＆＃34;提交应该去（子模块已经不是最简单的概念......）
嵌入二进制文件而不是子模块（但是开发子模块的更改呢？不同的log4net版本呢？）
有谁知道一个理智的解决方案？
答案 0 :(得分：6)
由于您要求的是理智的解决方案，我只能建议您设置自己的NuGet服务（查看http://www.MyGet.org获取灵感）
答案 1 :(得分：2)
IF 您沿着包管理的路线走下去，考虑一下OpenWrap。但是，将包管理工件嵌入源代码中是一个坏主意。您可以使用此类工具更新实际存储在子模块中的内容，但不要在构建时依赖它们。从构建脚本的角度来看，二进制文件就在那里。
答案 2 :(得分：1)
使用一个子模块来容纳所有“公共库”。只有一个级别。但是你应该将公共库作为具有明确定义的合同的服务。这样，您可以在没有停机时间的情况下逐步推出新版本。这样，每个只有一个子模块可以保存合同。这些可以是接口或消息。
答案 3 :(得分：1)
因此，如果我理解正确，问题出在Visual Studio而不是Git？如果是这种情况，请使用与Visual Studio一起使用的旧树结构。使您的子模块也构造一个树结构。因此，树的顶部将是一个超级仓库，其子模块（分支）将具有自己的子模块，直到您到达树的叶子。一开始设置会很痛苦，但它应该起作用。
答案 4 :(得分：1)
我在使用VS 2013时遇到了类似的问题。
我想直接使用git-svn而不是SVN。 SVN有一个庞大的目录集。我无法创建一个包含所有trunk文件夹的git-repository。 Git-总是退出并出现错误，存储库已损坏。我通过以下方式解决了这个问题：
Visual Studio的问题在于它无法识别我打开解决方案的主项目之外的多个项目。此解决方案位于一个文件夹中，该文件夹包含Visual Studio识别的仅受git-source控制的文件。
我尝试将git-preferences设置为使用上层父目录作为git-repostitory的位置，而没有注意到任何差异。