好吧，我的问题的简短版本是：
当您的项目在多个解决方案之间共享时，在 Git 中处理项目引用的最佳方法是什么？我的 Git 存储库应该如何组织？
长版本是：
我们是一个小型开发团队（5 名开发人员），目前我们使用 TFS 作为我们的源代码控制和构建服务器，Visual Studio 是我们选择的 IDE。我一直热衷于尝试新事物并尝试改善我们的开发环境，因此我决定阅读 Git，看看它是否可以很好地替代 TFS 的源代码控制部分。
我们刚刚将 Jira 集成到我们的工作流程中，因此我决定尝试使用 Stash 作为我们的 Git 环境，因为它与 Jira 的集成非常好。我现在正在尝试找出组织 git 存储库的方法，这就是我来这里的原因。现在我将描述我们组织了多少解决方案。
我们有很多解决方案。有些是库，有些是通过 Visual Studio 中的项目引用引用这些库的程序。
所以让我困惑的主要问题是如何处理许多解决方案中引用的库？
我们是否应该开始对库进行版本控制并将每个库放在单独的存储库中？当库收到必须部署的更新并且该库正在被 20 多个解决方案使用时，这种方式似乎会涉及大量额外的维护。我错了吗 ？
我看到的另一个缺点是 Visual Studio 中不再有项目引用，这会使调试变得更加乏味。
我是否应该使用我们所有的解决方案进行大型回购，这样我们所有的参考资料都是最新的？
我还认为也许我可以创建自己的 nuget 存储库，其中包含所有这些库，这样在需要时更新引用的库就不会那么麻烦了。这只是一个想法，我还没有正确研究过这一点，所以我不确定这是否有任何好处。
那么，有没有人可以给我一些关于这方面的建议？
不幸的是，这是没有单一答案的问题之一——这取决于情况。
最简单的解决方案始终是拥有一个存储库。这避免了管理具有不同版本的多个存储库的许多问题。但这只有在所有东西都只有一个版本的情况下才真正有效。同一存储库中的两个产品几乎不可能有不同的发布周期。那就是疯狂。当存储库增长到任何不显着的大小时，它也不会真正扩展。
正如蒂尔指出的，一种选择是Git 子模块 http://git-scm.com/book/en/Git-Tools-Submodules。这将允许您在特定提交或分支处动态地将一个存储库的源加载到另一个存储库中。当然，这还附带一个整体问题的主机 http://somethingsinistral.net/blog/git-submodules-are-probably-not-the-answer/，一些特定的子模块和其他子模块只是链接存储库的本质。*
有些人真的很喜欢Git 子树 http://blogs.atlassian.com/2013/05/alternatives-to-git-submodule-git-subtree/，这有点作弊，它允许您重复提取然后跨存储库导入文件夹的历史记录，然后再返回。
最后，您可以依赖依赖管理工具，具体取决于您的构建环境。我对 Visual Studio 的了解不够，无法发表评论。在 Atlassian，我们（目前）使用 Maven 来解决这个问题。如果您使用 JS，它可能是 NPM/Bower，在 Ruby 上它是 Gems。为了对程序 Y 进行微小的更改而不得不发布新版本的库 X 可能会令人沮丧，但在大多数情况下它运行得很好。
这确实是一个持续存在的问题，我知道有些事情每天都让我烦恼。我觉得可能有机会找到一个更好的解决方案，结合最好的子模块和依赖管理，但我还没有找到它。
我希望这有帮助吗？
* 除了工具问题之外，我自己对子模块最大的抱怨是它鼓励人们签入其他存储库的绝对 URL。这一切都很完美，直到您决定迁移 Git 服务器或其中一个存储库，但现在一切都崩溃了。前几天我发现你可以使用相对路径 https://stackoverflow.com/questions/1974181/cant-add-git-submodule-when-specified-as-a-relative-path，这很简洁，但并不能解决问题。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
