Git submodules wasn't a feature I used that often. Until we started to use it as a way to share context(agent.md) and skills between our projects. That's the moment we discovered that Git submodule support was missing in Visual Studio and we had to fall back to the terminal typing git submodule update --init --recursive
With Visual Studio 18.9, that finally changes. Submodules are now a first-class part of the Git experience in the IDE.
What was missing
Submodules are genuinely useful. They let you pull a shared library, an SDK, or a set of build scripts into your repository without copy-pasting code around. You could fall back to the command line, but the tooling was missing. Visual Studio would show you a submodule as a plain folder, with no indication of its state, no way to add or remove one from the UI, and no understanding of how it related to the parent repository. Every actual submodule operation meant tabbing out to the command line.
What you get now
Open a solution or folder that contains submodules, and Visual Studio discovers and activates them automatically. You'll notice a few things right away:
- A dedicated Submodules section in the Git Repository window.
- Submodule changes show up properly in Git Changes, instead of being invisible or lumped in confusingly.
- The branch and repository picker understands the parent-child relationship, so you can tell which repository you're actually looking at.
Remark: Submodules are kept out of the main local repositories list on purpose, so your repo picker doesn't turn into a pile of unrelated entries.
Adding, updating, removing
From the Submodules section in the Git Repository window, you can add, update, or remove a submodule directly. No memorized flags, no detour to a terminal. That alone covers most of what used to send people out of the IDE in the first place.
- Go to the Git –> Manage Branches window
- Hit the + icon in the Submodules section
- Specify a Name, Repository URL and Path
- That’s it!
Now you are good to go to start using the submodule.
Read-only by default
An important detail: most of the time you're consuming a submodule, not editing it. So Visual Studio treats submodules as read-only by default. That's a sensible default, it stops you from accidentally committing a change into a dependency you only meant to reference.
If you do need to work inside a submodule, it's a single setting:
Tools > Options > Source Control > Git > Automatically activate multiple repositories > Yes, include submodules
Flip that, and Visual Studio starts treating the submodule like any other repository you can commit into.
Tip: Leave the default in place unless you have an actual reason to modify the submodule. It's an easy way to avoid a "why did this dependency change" conversation later.
Is this the finished picture?
Not entirely. Microsoft is explicit about this being the first milestone, not the finish line. So far, I like the feature. It covers my day-to-day usage of submodules: discovery, visibility, add/update/remove.
The read-only guardrail makes sense and is a good default.
That's it! If you've been avoiding submodules in Visual Studio because the experience was frustrating, this is worth a second look.