There are different use cases which submodules solve. The following is a list of those I encountered so far (roughly ordered in perceived relevance): * Content shared between different repos: E.g. a library developed by you (or your fork of a public one) used in different projects. * Content managed by somebody else: E.g. a public library (you do not have push access to) used in your project. * Large and/or many files: To avoid the duration and disk cache pressure of examining or updating such data it can be put into a submodule to achieve an effect comparable to a sparse checkout (but which is easier to setup for each clone). Users can then decide if they want to ignore their changes (making commands like status and diff run significantly faster) and/or not updating them each time the commit recorded in the superproject changes. Upstream can provide reasonable defaults for these settings in the .gitmodules file. * Umbrella projects: E.g. different (maybe more or less connected) projects which are released together * Permissions: Putting sensitive information (e.g. SSH-keys or code under a NDA) into a submodule (which either has no remote or one that isn't public) to avoid accidental exposure of data. Please contact me if your use case doesn't fall into one of the above categories so I can update this list.