Can someone explain the difference between Submodules and Remotes?

A couple of days ago an admin here answered my post about sharing repos and suggest sub modules might be the way to do it.

I watched a few videos on Submodules, and they also had a video on Remotes, and they seem exactly the same to me from the descriptions. Can someone explain the difference between the two, and when would you want to use a remote versus when to use a sub module?

I am leaning towards Azure DevOps over GitHub. Microsoft has too many options that do the same thing.


They’re actually very different.

Remotes are names that you give to remote locations where the repository is stored. So when you clone a repository from GitHub to your local machine, the repository on GitHub is given a remote named origin in your local repository. This allows you to fetch, push, or pull your changes between your local repository and the copy that is stored on GitHub.

Submodules are for when you need to compose some other repository inside the main repository. For example, you’re working on a project that does some amazing thing. Then you create some library for this project that you want to store in a separate repository. You would create a separate repository for the library but then include that library into the main project as a submodule so that the entire project can be built all at once.

Virtually every Git repository has at least one remote. Very few projects use submodules if they are using modern dependency management tools

Hopefully this picture will help too …


This is not the type of remotes I am talking about.

I watched a video where a repository had shared Remotes that it used as references.

Either way, I don’t care. Git is too complicated to share all my projects. I just want to upload code.

1 Like