Workflow for using git submodules in Visual Studio

Question

I have some shared code I want to share among a number of solutions. Most examples use the command line, but I want to do it using Visual Studio 2013 (and/or TortoiseGi

Answer 1

After much experimenting...

In VS, add the shared projects from the submodule to the solution. They seem to live "outside" the parent solution as far as versioning.

If you make an edit to the submodule's projects, they are local. They need to be committed and pushed to the source repo, and then you need to merge them there. If you make changes at the source, you need to pull them manually into your solution's git submodule.

Problem is VS doesn't do any of this for you, so you need to use something like TortoiseGit or the command line.

Answer 2

We have found that the easiest way for us to do this is to move each of our shared units of code into their own Visual Studio Project and put each shared Visual Studio project in its own repo.

We then add each one of those projects as a submodule to any Solution that needs them. This is helpful since many of our projects can be very large in size and share many of the same chunks of code. We have made extensive use of nuget packages for this purpose, as well, but have generally had better success and a much better design/debug experience with submodules.

Much has changed at Microsoft in relation to Git in the last few years. Visual Studio Team Services (TFS Online) and On Prem-TFS (since TFS2015) both now have a good understanding of how submodules work and can now do CI Builds that incorporate submodules right out of the box.

Support in on-prem TFS 2015 can be a bit buggy, however. TFS Build's references to the submodules have a habit of becoming corrupted resulting in builds that stop working without warning until whichever submodule is at fault is completely removed and re-added - not a fun process. For this reason (among a few others), we are now using VSTS (TFS Online) for everything and have had none of those same types of problems. I would assume that this is fixed in on-prem TFS 2017, as well.

As was mentioned, Visual Studio itself (the IDE) does still have a hard time understanding submodule relationships. It really just can't handle them. I have tried a number of standalone Git Tools to find the easiest way to manage an environment like this. Tortoise seems to provide the easiest and most performant experience when pushing, pulling, and checking in to repos containing submodules. I usually use commands to add the submodules, but I suspect Tortoise's add submodule functionality works just fine, too.

When you commit code to a repo using Tortoise, it notices when a submodule is dirty and will prompt you to check-in the submodule before checking in the parent repo. That's really nice. Pulling or Fetching the parent repo can be a little confusing, though. It doesn't actually refresh the submodule from it's remote branch, it only refreshes it to whatever level is currently checked into the main repo remote which is not always the latest. In reality, this is the desired behavior, it's just not immediately intuitive if you're not expecting it.