Git 和 Visual Studio 项目参考

Posted 2023-02-15

【中文标题】Git 和 Visual Studio 项目参考

【英文标题】：Git and Visual Studio project references

【发布时间】：2014-03-14 20:13:31

【问题描述】：

好吧，我的问题的简短版本是：

当您拥有跨多个解决方案共享的项目时，在 Git 中处理项目引用的最佳方式是什么？应该如何组织我的 Git 存储库？

长版是：

我们是一个小型开发团队（5 名开发人员），目前我们使用 TFS 作为我们的源代码控制和构建服务器，Visual Studio 是我们选择的 IDE。我一直热衷于尝试新事物并尝试改进我们的开发环境，因此我决定阅读 Git 以了解它是否可以很好地替代 TFS 的源代码控制部分。 我们刚刚将 Jira 集成到了我们的工作流程中，因此我决定尝试将 Stash 作为我们的 Git 环境，因为它与 Jira 的集成度非常好。我现在正在尝试找出组织 git repos 的方法，这就是我在这里的原因。现在我将描述我们组织了多少解决方案。

我们有很多解决方案。有些是库，有些是通过 Visual Studio 中的项目引用引用这些库的程序。

所以让我感到困惑的主要事情是如何处理许多解决方案中引用的库？

我们是否应该开始对我们的库进行版本控制并将每个库放在一个单独的 repo 中？当库收到必须部署的更新并且该库被 20 多个解决方案使用时，这种方式似乎会涉及大量额外的维护。我错了吗 ？ 我看到的另一个缺点是 Visual Studio 中将不再有项目引用，这会使调试变得更加乏味。

我是否应该使用我们所有的解决方案进行大型回购，这样我们的所有参考资料都是最新的？

我还认为，也许我可以创建我们自己的包含所有这些库的 nuget 存储库，这样在需要时更新引用的库就不会那么麻烦了。这只是一个想法，我还没有仔细研究过，所以我不确定这是否有任何好处。

那么，有没有人可以在这方面给我一些建议？

【问题讨论】：

我认为“好吧，我的问题的简短版本将是”指向您的完整问题。

两个版本都问同样的问题，但较长的一个包含一些背景;)

你可能想看看 git 子模块的正确使用。

【参考方案1】：

不幸的是，这是没有单一答案的问题之一 - 这取决于。

最简单的解决方案是始终拥有一个存储库。这避免了管理具有不同版本的多个存储库的许多问题。但这只有在您拥有所有内容的单一版本时才真正有效；同一存储库中的两个产品几乎不可能有不同的发布周期。那就是疯狂。随着存储库增长到任何不显着的大小，它也不会真正扩展。

正如 Till 所指出的，一种选择是Git Submodules。这将允许您在特定提交或分支处动态加载一个存储库的源代码。当然，这带有一个完整的host of problems，一些特定的子模块和其他的只是链接存储库的本质。*

有些人真的很喜欢Git Subtree，这有点作弊，让您反复提取然后跨存储库导入文件夹的历史记录，然后再返回。

最后，您可以依赖依赖管理工具，具体取决于您的构建环境。我对 Visual Studio 知之甚少，无法发表评论。在 Atlassian，我们（目前）使用 Maven 来解决这个问题。如果你使用 JS，它可能是 NPM/Bower，在 Ruby 上它是 Gems。不得不发布新版本的库 X 只是为了对程序 Y 进行微不足道的更改可能会令人沮丧，但在大多数情况下它运行良好。

这确实是一个持续存在的问题，我知道的一些事情每天都让我烦恼。我觉得可能会有一个更好的解决方案的机会，它结合了最好的子模块和依赖管理，但我还没有找到它。

希望对你有帮助？

* 我自己对子模块的最大抱怨是，除了工具问题之外，它鼓励人们签入到其他存储库的绝对 URL。在您决定迁移 Git 服务器或其中一个存储库之前，这非常有效，现在一切都被破坏了。前几天我发现你可以使用relative paths，这很简洁，但不能解决问题。

【讨论】：

感谢您的回答。我对这个问题的了解越多，正如你所说，似乎没有最好的解决方案。我想我只需要权衡使用单个 repo 或使用依赖管理工具的利弊。

一个非常好的问题和一个非常公平的答案。谢谢你们两位。顺便说一句，有更新吗？有更好的处理方法吗？ TFS 可以很好地处理交叉解决方案引用，我认为 VS 的 git 插件应该得到改进，以完成与 TFS 插件相同的事情。

不幸的是，Visual Studio 2015 中的 git 集成似乎没有解决这个问题。除非我错过了什么？