CODEWITHSUNDEEP
c#gitvisual-studiotfstfvc
Eric Ouellet
Eric Ouellet

Reputation: 11754

What is the Visual Studio behavior when using GIT per project?

After reading about using GIT with Visual Studio solution, I understand that it is preferable to use GIT per project, at least for project which represent a (re-usable) common library. If you have a solution with many projects specific to that solution, using only one repository could be acceptable. For common library, it appears logical to me to have one repository for it in order to be able to fix bugs in the common library from where you detect it and have only one history for all changes.

Using one GIT per common project means that you have more than one GIT repository for any solution that produce an executable that use one or more common library.

According to this: Visual Studio suggestion - Allow multiple Git repositories to be active at once, Visual Studio seems to not support many GIT repository seamlessly. (1995 request)

Does Visual Studio 2017 implement the previous suggestion and manage many GIT repository per solution? (ex: one per project for some projects and one per solution for the solution itself and all other specific projects to this solution)? In other words, does Microsoft will see and manage changes per project/GIT or do I have to works with only one GIT at the solution Level?

Just as a side one (this is not the primary question - the real question is in the previous paragraph): If Visual Studio does not allow multiple GIT repo to be active at once, wouldn't be better to stick with TFS for the moment for any development with common library?

Upvotes: 2

Views: 1599

Answers (2)

Gaute Løken
Gaute Løken

Reputation: 7912

While there has not been great support for multi repo solutions in the past, this is about to change. In Visual Studio 16.11 Preview 1, there is now a much more fully featured Git client, multiple repositories are detected and users can easily switch between them using a repository selector in the status bar.

See this blog for further information: Enhanced Productivity with Git in Visual Studio

Upvotes: 2

jessehouwing
jessehouwing

Reputation: 114857

This is a controversial topic. You have a few options:

  • Mono-repo. All your code lives in a single repository, whether they're split up into separate solutions or not is up to you. If your dependencies are "possibly reusable" then this is the simplest starting point. If you ever really start to reuse your components, you can always break them out.
  • Separate repositories + Package Manager (npm, Nuget). Put each reusable project in a separate solution, optionally in a separate repository. Have a CI build automatically create a package and publish it to the VSTS package management feed.
  • SubModules: Create a master repository with your solution, create a separate repository for each reusable component with just the csproj and the sources for that component. Visual Studio 2017 has rudimentary support for submodules. But with a separate git client on the side (Tower, SourceTree) or simply with some commandline mastery, you can make this work just fine.
  • Subtree: Create a master repository with your solution, create a separate repository for each reusable component with just the csproj and the sources for that component. Visual Studio 2017 has no support for subtrees at the moment. But with a separate git client on the side (Tower, SourceTree) or simply with some commandline mastery, you can make this work just fine.
  • Multi-repo: Create separate repositories for each project, put a solution alongside it. Manage each sub-component separately and there is no concept of a submodule tracking. Visual Studio will actively fight you in this setup, as it will only support a single master repository at a time

In the end it is your choice. Each solution has its own benefits and there are examples of each out there. The Windows sources are all stored in a single monstrous mono-repo with all its reusable components in the same repository. It has great advantages with regards to knowing which files and which versions work together and which won't. But the repository is so big that Microsoft built GVFS in order to allow their developers to work on a 300GB working directory.

If your components are currently not being re-used and if your tests are more integration tests than real unit tests, then it makes sense to join them up into the same repository.

You can always decide to fix this when the need arises. You can always try to keep these projects as separate as possible. The .NET route will most logically lead you to Nuget though... Also because it handles the versioning aspects and the ease of sharing between projects without having to build the sources everywhere.

Upvotes: 3

Related Questions