我正在使用Sharelatex(github)创建一个网站，但它包含其他用于构建主项目的存储库。我在git中遇到了子模块，但由于主项目不包含任何子模块，所以我无法使用它。实际上，您确实有一个子模块。这就是嵌套存储库的作用，这也是理解子模块的所有内容（我很认真），需要理解的内容。要理解子模块，请想象您拥有一个嵌套存储库（您确实拥有），并考虑管理要求，在dvcs中支持该设置需要做什么。
首先，当人们从包含已发布提交的某个repo克隆使用子模块的项目时，该克隆显然不会获取子项目存储库（当然不应该获取您的私有版本）。因此，他们还必须从其自己的已发布存储库中获取子项目存储库。
如何告诉提取您的提交的人在哪里获取必要的子项目提交？显然，您必须在提交的文件中放置一个注释，说明“这是一个应该具有任何所需$subproject提交”的repo。`git submodule`已经确定将`.gitmodules`作为存储此类注释的常规位置。
接下来：如果您交给别人的url离线了，其他人该怎么办？他们显然需要使用另一个repo。因此，`.gitmodules`只是建议，`git submodule`命令使用您的`.git/config`中的当前值，`git submodule init`已经从`.gitmodules`中的建议值填充了它。
`git submodule`的操作都是这样的。忘掉它。在需要一些帮助进行已发现需要执行的任务时，甚至不必查看该命令。从知识，简单事实开始，即子模块只是一个嵌套存储库，使用它的项目提交的只是应该在该嵌套存储库中的提交ID。这就是全部。这就是子模块的全部内容。
当您遇到需要执行的繁琐任务时，请寻找可以为您完成它们的`git submodule`子命令。您不必使用子命令。所有子命令要做的就是自动化否则将很费力的直接任务。这是一个工具包，可用于执行所需的任何操作，并且无论如何，它都不能或不应强加某些任意和足够（<--这是困难的部分）的抽象层面。所以这是一个杂包。
话虽如此，当执行
git submodule update 和
git submodule add 时，它们为你执行
git clone 时有一个重要的安全措施。传统上，仓库真正的内容位于子项目的顶层目录下的
.git，但如果你检出的分支中没有该子项目，或者不需要或不想要该子项目，则它的
.git 也会消失——这并不是你想要的，因为它不仅包含你检查过的内容，还包含整个实际的仓库内容。因此，当
git submodule update 执行初始克隆时，它将子模块的
.git 目录提升到包含项目仓库中的一个便利（而且任意）小角落，并用包含在子模块中移动的相对路径替换了刚刚移出子模块的
.git 目录。
为了在当前仓库上完成这个初始提升，请将其移到当前仓库之外，在任何地方添加和更新，然后修复
.gitmodules 中的上游 URL，以方便其他人使用。
现在，你已经完全了解了 Git 子模块，并可以在需要时逐步获取详细信息，以了解
git submodule 命令为你做了什么，以及为什么你实际上不必在前期就关心了解其手册中的每一个细节。至少我认为是这样。
如果我漏掉了任何重要内容，请在评论中指出（温和或直接，我真的不介意）。
