Git和Visual Studio项目参考 [英] Git and Visual Studio project references

问题描述

那么，我的问题的简短版本是:

Alrighty then, the short version of my question would be:

当您的项目在多个解决方案中共享时，在Git中处理项目引用的最佳方法是什么?应该如何组织我的Git仓库?

What is the best way to handle project references in Git when you have projects that are shared across multiple solutions and how should my Git repos be organized?

长版本为:

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

We are a small dev team(5 developers) and currently we use TFS as our source control and build server and Visual Studio is our IDE of choice. I've always been keen on trying new things and trying to improve our dev environment so I decided to read up on Git to find out if it would be good replacement for the source control part of TFS. We just integrated Jira into our workflow so I decided to try out Stash as our Git environment because of how well it integrates with Jira. I'm now in the process of trying to find out what way to organize the git repos and that is why I'm here. Now I'm going to describe how many of our solutions are organized.

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

We've got a bunch of solutions. Some are libraries and some are Programs that reference these libraries via Project reference in Visual studio.

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

So the main thing that confuses me would be how to handle libraries that are referenced in many solutions?

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

Should we start versioning our libraries and put every library in a separate repo? It seems like this way would involve a lot of extra maintenance when a library receives an update that has to be deployed and that library is being used by 20+ solutions. Am I wrong ? One more downside that I see is that there would be no more Project references in Visual studio and it would make debugging a lot more tedious.

我是否应该使用我们所有的解决方案进行大规模回购，这样我们的所有参考文献都是最新的?

Should I just make on big repo with all our solutions and that way all our references are up to date?

我还认为，也许我可以建立自己的nuget存储库，其中包含所有这些库，这样，在需要时更新引用的库就不会有太多麻烦.这只是一个主意，我没有对此进行适当的研究，因此不确定是否有什么好处.

I also thought that maybe I could make our own nuget repository that has all theses libraries and that way it would not be as much of an hassle to update the referenced libraries when needed. This is just an idea and I have not looked into this properly so I'm not sure if this would be of any benefit.

那么，有没有人可以给我一些建议呢?

So, are there any people out there that could give me some advice regarding this?

推荐答案

不幸的是，这是一个没有一个答案的问题之一-它取决于.

This is one of those questions that unfortunately doesn't have a single answer - it depends.

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

The easiest solution is always to have a single repository. This avoids many of the problems of managing multiple repositories with different versions. But this only really works if you have a single version of everything; it's almost impossible to have different release cycles for two products in the same repository. That way lies madness. As repositories grow to any non-significant size it also doesn't really scale.

正如Till所指出的，一个选项是 Git子模块.这将允许您在特定的提交或分支处将一个存储库的源动态加载到另一个存储库中.当然，这会伴随整个大量问题 ，某些特定的子模块，而另一些则只是链接存储库的性质.*

As Till points out, one option is Git Submodules. This will allow you to dynamically load the source of one repository in another at a specific commit or branch. Of course this comes with a whole host of problems, some specific so submodules and others are just the nature of linking repositories.*

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

Some people really like Git Subtree, which is somewhat cheating and lets you repeatedly extract and then import the history of a folder across repositories, and back again.

最后，您可以依赖于依赖项管理工具，具体取决于您的构建环境.我对Visual Studio的了解不够多，无法发表评论.在Atlassian，我们(当前)使用Maven解决此问题.如果您使用的是JS，则可能是NPM/Bower，而在Ruby上则是Gems.仅仅为了对程序Y进行微不足道的更改而不得不发行新版本的Library X可能会令人沮丧，但是在大多数情况下，它运行得很好.

Finally, you can rely on a dependency management tool, depending on your build environment. I don't know enough about Visual Studio to comment. At Atlassian we (currently) use Maven to solve this. If you were using JS it might be NPM/Bower, on Ruby it's Gems. It can be frustrating to have to release a new version of Library X just to make a trivial change for Program Y, but for the most part it works well enough.

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

This is really an ongoing problem, and something I know vexes me on a daily basis. I feel like there could be an opportunity for a better solution that combines the best of submodules and dependency management, but I haven't found it yet.

我希望对您有帮助吗?

*除了子工具之外，我对子模块最大的困扰是它鼓励人们签入其他存储库的绝对URL.直到您决定迁移Git服务器或其中一个存储库，而现在一切都已损坏，这才可以正常工作.我发现有一天您可以使用相对路径，这很简洁，但不能解决问题.

* My own biggest gripe with submodules, tooling issues aside, is that it encourages people to check in absolute URLs to other repositories. This works perfectly until you decide to migrate your Git server, or one of the repositories, and now everything is broken. I found out the other day you can use relative paths, which is neat but doesn't solve the problem.

这篇关于Git和Visual Studio项目参考的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！