面对比较复杂的项目，我们有可能会将代码根据功能拆解成不同的子模块。主项目对子模块有依赖关系，却又并不关心子模块的内部开发流程细节。
这种情况下，通常不会把所有源码都放在同一个 Git 仓库中。
有一种比较简单的方式，是在当前工作目录下，将子模块文件夹加入到 .gitignore 文件内容中，这样主项目就能够无视子项目的存在。这样做有一个弊端就是，使用主项目的人需要有一个先验知识：需要在当前目录下放置一份某版本的子模块代码。
还有另外一种方式可供借鉴，可以使用 Git 的 submodule 功能，这也是接下来准总结的内容。
实际上 Git 工具的 submodule 功能就是建立了当前项目与子模块之间的依赖关系：子模块路径、子模块的远程仓库、子模块的版本号。
使用流程
假定我们有两个项目：project-main 和 project-sub-1，其中 project-main 表示主项目，而 project-sub-1 表示子模块项目。
其中 project-main 的远程仓库地址为 https://github.com/username/project-main.git，而 project-sub-1 的远程仓库地址为 https://github.com/username/project-sub-1.git。
接下来，我们希望在 project-main 中添加 project-sub-1 ，而又保持 project-sub-1 自身独立的版本控制。
1.创建 submodule
使用 git submodule add <submodule_url> 命令可以在项目中创建一个子模块。
如：
git submodule add https://github.com/xjh22222228/project-sub-1.git
此时项目仓库中会多出两个文件：.gitmodules 和 project-sub-1 。
前者的内容是这样的，事实上就是子模块的相关信息；而后者那个文件，实际上保存的是子模块当前版本的版本号信息。
[submodule "project-sub-1"]
path = project-sub-1
url = xxxxxxxx
事实上，此时在 .git/config 文件中也会多出一些信息，在 .git/modules 文件夹下也会多出一份内容。
新建的子模块，对应的都是master分支，可以使用下面的指令，比如切换到test分支
git config -f .gitmodules submodule.common.branch test
添加完子模块之后记得一定要进行一次推送，这样子模块的更新才能更新的远程仓库中，使用 git commit -m "add submodule xxx" 提交一次，表示引入了某个子模块。提交后，在主项目仓库中，会显示出子模块文件夹，并带上其所在仓库的版本号。
2.获取 submodule
上述步骤在创建子模块的过程中，会自动将相关代码克隆到对应路径，但对于后续使用者而言，对于主项目使用普通的 clone 操作并不会拉取到子模块中的实际代码。
如果希望子模块代码也获取到，一种方式是在克隆主项目的时候带上参数 --recurse-submodules，这样会递归地将项目中所有子模块的代码拉取。
git clone xxxxxxx --recurse-submodules
此时 project-main/project-sub-1 文件夹是有内容的，并且固定在某个 Git 提交的版本上。
另外一种可行的方式是，在当前主项目中执行：
git submodule init
git submodule update
则会根据主项目的配置信息，拉取更新子模块中的代码。
拉取指定子模块的更新内容，如子模块project-sub-1
git submodule update --remote project-sub-1
切换分支或者克隆父项目后，所有的子模块分支都指向 detached head， 为了修复这个问题，直接在根项目执行：
git submodule foreach -q --recursive 'git checkout $(git config -f $toplevel/.gitmodules submodule.$name.branch || echo master)'
执行去除detached head操作指令后需要切换到我们需要的分支中，先修改gitmodules的文件分支记录
git config -f .gitmodules submodule.common.branch test
3.子模块内容的更新
对于子模块而言，并不需要知道引用自己的主项目的存在。对于自身来讲，子模块就是一个完整的 Git 仓库，按照正常的 Git 代码管理规范操作即可。
对于主项目而言，子模块的内容发生变动时，通常有三种情况：
（1）当前项目下子模块文件夹内的内容发生了未跟踪的内容变动；
（2）当前项目下子模块文件夹内的内容发生了版本变化；
（3）当前项目下子模块文件夹内的内容没变，远程有更新；
情况1：子模块有未跟踪的内容变动
对于第1种情况，通常是在开发环境中，直接修改子模块文件夹中的代码导致的。
此时在主项目中使用 git status 能够看到关于子模块尚未暂存以备提交的变更，但是于主项目而言是无能为力的，使用 git add/commit 对其也不会产生影响。
在此情景下，通常需要进入子模块文件夹，按照子模块内部的版本控制体系提交代码。
当提交完成后，主项目的状态则进入了情况2，即当前项目下子模块文件夹内的内容发生了版本变化。
情况2：子模块有版本变化
当子模块版本变化时，在主项目中使用 git status 查看仓库状态时，会显示子模块有新的提交
在这种情况下，可以使用 git add/commit 将其添加到主项目的代码提交中，实际的改动就是那个子模块 文件 所表示的版本信息，代码示例：
-Subproject commit ace977071f94f4f88935f9bb9a33ac0f8b4ba935
+Subproject commit 7097c4887798b71cee360e99815f7dbd1aa17eb4
通常当子项目更新后，主项目修改其所依赖的版本时，会产生类似这种情景的 commit 提交信息。
情况3：子模块远程有更新
通常来讲，主项目与子模块的开发不会恰好是同时进行的。通常是子模块负责维护自己的版本升级后，推送到远程仓库，并告知主项目可以更新对子模块的版本依赖。
在这种情况下，主项目是比较茫然的。
之前曾经提到，主项目可以使用 git submodule update 更新子模块的代码，但那是指 当前主项目文件夹下的子模块目录内容 与 当前主项目记录的子模块版本 不一致时，会参考后者进行更新。
但如今这种情况下，后者 当前主项目记录的子模块版本 还没有变化，在主项目看来当前情况一切正常。
此时，需要让主项目主动进入子模块拉取新版代码，进行升级操作。
通常流程是：
cd project-sub-1
git pull origin master
子模块目录下的代码版本会发生变化，转到情况2的流程进行主项目的提交。
当主项目的子项目特别多时，可能会不太方便，此时可以使用 git submodule 的一个命令 foreach 执行：
git submodule foreach 'git pull origin master'
情况汇总
终上所述，可知在不同场景下子模块的更新方式如下：
- 对于子模块，只需要管理好自己的版本，并推送到远程分支即可；
- 对于父模块，若子模块版本信息未提交，需要更新子模块目录下的代码，并执行 commit 操作提交子模块版本信息；
- 对于父模块，若子模块版本信息已提交，需要使用 git submodule update ，Git 会自动根据子模块版本信息更新所有子模块目录的相关代码。
4.删除子模块
根据官方文档的说明，应该使用 git submodule deinit 命令卸载一个子模块。这个命令如果添加上参数 --force，则子模块工作区内即使有本地的修改，也会被移除。
git submodule deinit project-sub-1
git rm project-sub-1
执行 git submodule deinit project-sub-1 命令的实际效果，是自动在 .git/config 中删除了以下内容：
[submodule "project-sub-1"]
url = xxxxxx
执行 git rm project-sub-1 的效果，是移除了 project-sub-1 文件夹，并自动在 .gitmodules 中删除了以下内容：
[submodule "project-sub-1"]
path = project-sub-1
url = xxxxxx
此时，主项目中关于子模块的信息基本已经删除（虽然貌似 .git/modules 目录下还有残余）
接下来可以提交代码：
git commit -m "delete submodule project-sub-1"
如果项目移除掉原来的子模块 可以去.git文件中删除相关的配置文件，.git文件夹中的modules记录的就是子模块的信息
总结
当项目比较复杂，部分代码希望独立为子模块进行版本控制时，可以使用 git submodule 功能。
使用 git submodule 功能时，主项目仓库并不会包含子模块的文件，只会保留一份子模块的配置信息及版本信息，作为主项目版本管理的一部分。
