33

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

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

长版本是：

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

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

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

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

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

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

那么，有没有人可以给我一些关于这个的建议？

4

1 回答 1

23

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

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

正如 Till 指出的那样，一种选择是Git Submodules。这将允许您在特定提交或分支处动态加载一个存储库的源代码。当然，这会带来很多问题，一些特定的子模块和其他只是链接存储库的本质。*

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

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

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

我希望这有帮助吗？

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

于 2014-02-15T19:07:28.450 回答