中科院张老师说起来挺有意思的，我当初是在一个内部系统改造时第一次被submodule击中。项目里要同时维护一个公共权限库和两个业务端，业务端还需要反哺公共库的修复。最初为了省事，我直接把公共库代码复制到一个common目录里提交了，结果不到两周就后悔——每次权限库更新，我都要手动拷一遍代码；而业务端改了公共代码，修改也根本回不到源头。后来认真梳理了一遍Git submodule的工作方式，才算彻底把这类“项目依赖另一个项目”的关系理顺了。
这篇内容就围绕Git submodule展开，从它解决什么问题、底层怎么工作，到add、clone、update、删除、分支切换这一整套实操，再到报错排查和选型对比，一步不落。适合正在维护多个仓库、想从“人工拷贝”升级为“真正引用”的开发者，也适合刚接触子模块、被各种fatal报错劝退的新手。
1. 先从使用场景说起：为什么会有submodule这个功能
1.1 一个仓库套另一个仓库的困境
假设你手头有这样一个系统：主项目叫web-portal，里面大量用到团队维护的UI组件库ui-kit。简单场景下，你把ui-kit的源码直接放到web-portal里一份，然后继续开发，似乎没什么问题。但一旦ui-kit是独立迭代、独立发版、被多个系统复用的库，你很快就发现：
- 你的仓库里那份代码是某个时间点的快照，时间一久根本不知道对应ui-kit的哪个tag；
- ui-kit修复了一个bug、升级了一个依赖，你想要同步就得重新把文件拷一遍；
- 最要命的是，有人在web-portal里顺手改了ui-kit的源码做定制，这些改动既不会出现在ui-kit仓库里，也没有任何记录说明改过；
- 版本回退时也比较混乱，主项目回滚到旧版，但common目录里的代码是新的，行为和代码对不上。
这时候你会自然想到一种需求：web-portal能不能像“引用”一条数据一样，引用ui-kit仓库的某个确定版本？Git给出的答案之一就是submodule。
1.2 常见方案的横向对比
在回答“要不要上submodule”之前，我经常把几条路线摆到一起看。
方案A：直接把三方代码拷进仓库里
适合那些彻底不打算再跟随上游的第三方库，或者是临时赶工、代码量极小的场景。优点是简单，拉下去就能编译；代价是靠人工维护同步关系，几乎必然出现某个版本代码丢失、改动无记录的问题。
方案B：用包管理器来管理依赖
比如npm、Maven、pip这类，适合语言层面的依赖。优点是版本清晰、锁文件可以精确复现；但它的前提是依赖库必须打到包仓库里，而且通常是以构建产物或约定目录的形式存在。如果你的“依赖”是协议文件、配置文件、一键部署脚本，甚至是另一套完整的服务定义，包管理器往往并不合适。
方案C：把所有代码放到一个monorepo大仓库里
代码统一在一个仓库里，可以一起构建，原子提交也方便。但对于跨团队权限控制、多个仓库独立发布、历史体积增长这类问题，monorepo会带来更多管理压力。
方案D：Git submodule
它不复制文件副本，也不打包成中间产物，而是在主仓库里记录“某个子仓库的某个提交号”。只要子仓库在远端还能访问，任何人克隆主项目并执行submodule update，就能拿到完全一致的版本。
我做团队基础设施时，最终把内部“跨项目共享的配置仓库”这件事交给了submodule，核心原因有两个：它和目标仓库保持一致的Git历史，改动可以双向同步；同时它是Git原生能力，使用者不需要额外安装工具链。
1.3 submodule的定位
说直白一点，submodule是“用Git引用Git”的机制。它的核心思路是：主仓库不保存子仓库的文件内容，只保存一条指向子仓库某次提交的引用。这个引用也叫gitlink。你看主仓库目录时，子模块目录就像个普通文件夹，但它右键看状态时有自己的版本号、自己的分支、自己的远端。
理解到这一层再往下走，很多操作就不会懵了，比如为什么子模块目录经常显示“脏”，为什么改了代码要先在子模块里提交，主仓库的提交才会更新引用，这些都在等会儿的正文里展开。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. submodule的核心工作机制：一个指针和三份状态
2.1 gitlink、.gitmodules文件与子模块内嵌仓库
先把submodule的三个关键载体讲清楚。
当你在主仓库里执行：
bash复制git submodule add https://github.com/example/ui-kit.git common/ui-kit
Git会做三件事：
- 在版本库里记录一个名为gitlink的特殊索引项，它不像普通文件那样保存内容，而是记录“common/ui-kit这个路径对应ui-kit仓库的哪个提交”；
- 在主仓库根目录生成或更新
.gitmodules文件； - 在子模块的
.git文件里放一个指向主仓库内部gitdir的路径，让子模块成为一个“托管在主仓库里的独立仓库”。
其中.gitmodules文件是submodule的“通讯录”，内容大致是：
ini复制[submodule "common/ui-kit"]
path = common/ui-kit
url = https://github.com/example/ui-kit.git
也就是说url被正式记录下来，后续其他成员克隆主项目后，就能根据这份文件知道去哪里拉取子模块。要注意的是，.gitmodules文件不是给Git自己看历史的，而是给“初始化”过程用的。
2.2 主仓库记录的是提交号而不是分支
这是好多人踩坑的第一道坎。主仓库的索引中保存子模块的“当前HEAD提交号”，它的形态在git diff里看起来类似：
diff复制diff --git a/common/ui-kit b/common/ui-kit
index 8f2c33a..1ab44e2 160000
--- a/common/ui-kit
+++ b/common/ui-kit
@@ -1 +1 @@
-Subproject commit 8f2c33a9e11d4bd1a6a5c4f6c76e4f
+Subproject commit 1ab44e2c8f01a97d1e2d8c0ab3e1f5
注意那个160000，这是Git里的模式，表示它是一个“目录+gitlink”的组合，不是常规文件，也不是普通目录。
父仓库不会关心子模块当前在哪个分支上，不会关心你是不是detached HEAD，它只关心一件事：这个路径现在指向哪个commit。只要commit号变了，父仓库就觉得子模块“变了”。
我通常会给团队成员打这样一个比方：父仓库的提交，是一张拍了照片的记录单。照片里只圈定“ui-kit所在的那一格”是放进哪张卡，但卡片内部全貌完全取决于那张卡本身。如果你的协作流程没有控制好子模块的提交习惯，很容易出现主仓库记录到了某个临时comit，其他人一updata就跑到别人正在开发的半成品上。
2.3 初始化与更新：init和update各做什么
刚克隆下来的主仓库，子模块目录实际上基本都是空的，只是目录占位。因为父仓库根本不存子仓库的文件，别人家也只是知道“该去哪里拉”而已。
第一次拉取子模块的标准流程是：
bash复制git submodule init
git submodule update
git submodule init做的事情，是把.gitmodules文件里的配置写入到你本地仓库的.git/config中。为什么要这么设计？因为不同人可能需要在本地覆盖子模块的远端地址。比如源码库在内部服务器，但你希望用镜像拉取，你可以init之后手动改.git/config里的url，而.gitmodules保持团队约定不动。
git submodule update做的事情，是按父仓库记录的commit号去拉取并检出子模块代码。它会进入子模块目录、fetch远端、再checkout到记录的commit，并且处于detached HEAD状态。这个“detached”后面会细讲。
所以init + update组合起来，才完成了“我知道去哪拉 + 把代码铺下来”的完整动作。
现在的Git版本还支持缩写方式：
bash复制git submodule update --init
如果连.gitmodules里的子模块都还没在索引里，更彻底的做法是：
bash复制git submodule update --init --recursive
--recursive适用于子模块里还嵌套了子模块的情况，一次性把整棵树拉干净。
3. 实操记录：从添加子模块到日常维护的完整流程
3.1 环境准备：先确认Git版本与SSH配置
在开始之前，先把基础工作补上。无论你是从官网下载安装包，还是用包管理器安装，装完都建议确认一下版本：
bash复制git version
我这里用的环境是Windows 11 + Git 2.40，但下述命令在macOS、Linux上行为一致。
如果你想通过SSH协议操作托管在GitHub、GitLab或自建Git服务器上的仓库，可以不每次输入密码。Windows下我一般用系统自带的OpenSSH，把公钥放到代码托管平台后，本地测试：
bash复制ssh -T git@github.com
看到成功的欢迎语就算配置完成。submodule在clone阶段会用到这个SSH连通性，如果配好了免密，后续在子模块里执行fetch和push会顺滑很多。
如果不用SSH而使用HTTPS，则clone/update阶段基本都要推拉，有些平台还需要个人访问令牌，建议优先配好SSH。
这里插一句，网上经常看到类似这样的命令串：
bash复制git -c diff.mnemonicprefix=false -c core.quotepath=false --no-optional-locks ...
这通常是某些IDE或图形工具在点击操作时自动生成的调用参数，core.quotepath=false是为了让中文文件名正常显示，diff.mnemonicprefix=false是为了统一diff的a/ b/前缀，--no-optional-locks是为了不让git status之类的操作创建锁文件。
这些参数不影响submodule的机制，但如果你在日志里看到了，大概知道是外部工具调用的即可。
3.2 给已有项目添加一个子模块
假设主项目在本地路径~/work/web-portal，需要挂载一个子仓库git@github.com:example/shared-config.git到config/shared目录。
进入主项目：
bash复制cd ~/work/web-portal
git submodule add git@github.com:example/shared-config.git config/shared
执行成功后，Git会做下面这些事：
- 自动创建
config/shared目录，并把shared-config仓库克隆到那里； - 子模块默认处于detached HEAD状态，指向当前默认分支的最新commit；
- 在
.gitmodules文件里写路径和url； - 在索引里创建gitlink，此时
git status应该能看到两个变化。
然后提交：
bash复制git add .gitmodules config/shared
git commit -m "chore: add shared-config as submodule"
git push
到这里，远端仓库就正式包含了子模块的引用信息。以后任何团队成员克隆主项目后用update --init，都能拉出和自己记录一致的内容。
注意：此时不要在子模块目录里执行爸爸仓库的git add .完事，那样虽然也能把gitlink的变化加进去，但如果你之后进到子模块改了内容，状态会变得更加难以区分。比较好的习惯永远是先分别查看主仓库和子模块的git status。
3.3 克隆一个带子模块的项目
如果是新环境第一次拉取：
bash复制git clone git@github.com:example/web-portal.git
cd web-portal
这个时候你会发现config/shared目录存在，但是很空或为空。这是正常现象，因为父仓库真的没存子模块文件。
接着执行：
bash复制git submodule update --init
如果你要一次性把所有嵌套子模块也拉下来：
bash复制git submodule update --init --recursive
如果想在克隆主仓库时顺带拉取所有子模块，也可以直接：
bash复制git clone --recursive git@github.com:example/web-portal.git
我个人的习惯是：即便当时不需要子模块内容，也执行一次update --init，因为很多配置读取型仓库，缺了它，项目根本跑不起来。
还有个容易忽视的点：如果子模块的URL因为团队迁移仓库导致变化了，clone之后的update会报错或拉取到旧地址。此时需要在.gitmodules里修改url，然后执行：
bash复制git submodule sync
sync这个命令的作用是，把.gitmodules中的URL同步到本地.git/config。很多人改完.gitmodules里面的url后，忘了执行sync，结果执行update时仍然按照旧的url去请求，这是典型的操作顺序遗漏。
3.4 日常开发：子模块内部改代码并同步到父仓库
现在进入最常见的场景：在租户项目里同时维护子仓库代码。
第1步，进入子模块目录：
bash复制cd config/shared
第2步，你可以先切到一个分支再改，否则会处于detached HEAD状态。切到main分支并拉取最新代码：
bash复制git checkout main
git pull
第3步，修改文件，在子模块里单独提交、推送：
bash复制git add .
git commit -m "feat: update default theme"
git push
第4步，回到主仓库目录，现在你会看到config/shared显示为modified，原因是它记录的commit号变了：
bash复制cd ..
git status
第5步，在主仓库里提交这个变化：
bash复制git add config/shared
git commit -m "chore: bump shared-config"
git push
完成这五步之后，其他人拉取主仓库、运行git submodule update，才能拿到你最新推送到子模块的那个commit。如果只执行了前3步，子模块在远端虽然有了新内容，但父仓库的引用还指向老commit，别人根本同步不到。
这里我多说一句：submodule的开发流程颠覆了很多人的“一个提交包含所有改动”的习惯。你没法像monorepo那样在父仓库里一键提交所有跨仓库修改，必须先在子仓库提交、推送，再回父仓库更新引用、提交推送。所以团队里要约定清楚：共享库的改动归谁负责，是否需要走review流程。否则很容易出现“我明明改了common目录，怎么push不到子模块远端”的疑惑。
3.5 更新子模块到远端最新版本
在父仓库里，如果只想拉取所有子模块的最新提交并切换到最新状态：
bash复制git submodule update --remote
这个命令会进入每一个子模块，在各自默认分支（假设是main）拉取最新代码，并将子模块更新到最新的remote分支commit。但注意，它只是更新了子模块的工作区，父仓库索引里记录的commit号也变了，你依然需要在父仓库里再做一次git add和git commit，才能把这次升级固化下来。
不带--remote的普通更新：
bash复制git submodule update
则是按照父仓库当前记录的commit去检出，也就是“回到锁定版本”。如果你在子模块里做了临时修改，这个命令可能会报错或覆盖掉改动，务必谨慎。
日常我最常用的组合是：
bash复制git submodule update --init --recursive
git submodule foreach git pull origin main
foreach可以对所有子模块批量执行任意Git命令，很方便。比如想批量查看状态：
bash复制git submodule foreach git status
如果你的子模块不少，这个命令比一个个目录进去敲要高效得多。
3.6 切换分支时如何处理submodule
一个很常见的困惑：我在主仓库的feature分支和main分支之间切换，为什么submodule目录里的代码老是变来变去？
这是因为每个分支都可能记录了不同的子模块commit号。当你切换主仓库分支时，Git会尽量把子模块目录更新到对应分支锁定的commit。如果本地子模块没有新改动，一般能静默完成；如果子模块里有未提交的改动或子模块HEAD处于不同分支，就可能报错或留下脏状态。
我建议的策略是：在切换主仓库分支之前，先进到子模块目录确认它是否干净，必要时提交或暂存：
bash复制cd config/shared
git status
git stash
干净之后再回到父仓库执行git checkout。如果你的主分支间的子模块版本差异比较大，切完分支后最好跑一次：
bash复制git submodule update
把子模块强制对齐到新分支的记录点。
3.7 移除submodule的完整操作
submodule的删除比添加要麻烦一些，不能简单地右键删除目录。标准的移除过程如下：
第1步，先取消注册子模块：
bash复制git submodule deinit -f config/shared
deinit会清除.git/config里的submodule配置，并清空子模块工作区目录。
第2步，从Git索引中移除gitlink：
bash复制git rm -f config/shared
这会把索引里的条目删除，同时也会删除物理目录。
第3步，删除.gitmodules中对应的块。可以用编辑器打开手动删，也可以用以下命令确认还有没有相关残留：
bash复制git config -f .gitmodules --remove-section submodule.config/shared
如果你用的是新版本Git，git rm步骤之后，.gitmodules里的块有时会自动清理，不放心就手动检查一下。
最后提交：
bash复制git add .
git commit -m "chore: remove shared-config submodule"
git push
3.8 给仓库打tag时不能忽略子模块
如果你要给整个项目打一个发布tag，或者做版本回溯，这里有一个经常被忽视的点：父仓库的tag只记录子模块commit号，而不保存子模块内容。
也就是说，线上服务器检出你的tag之后，必须执行git submodule update --init，才能把对应版本的子模块代码拉下来。否则你看到的配置目录是空的，服务起不起来，但你翻遍主仓库日志都觉得莫名其妙。
我在内部的发布脚本里会强制加上这一句，同时在打包产物时把子模块目录也纳入归档，避免运行时依赖Git仓库。
4. 避坑指南：常见报错与排查方法
4.1 热身问题：fatal: needed a single revision
热搜词里有一条非常典型：git submodule update fatal: needed a single revision。这里我展开讲下。
这个报错的完整场景通常是：你执行git submodule update，结果它说需要“一个单独的修订版本”，言下之意是子模块里无法解析出父仓库记录的commit号。
出现这个问题的原因是多方面的，最常见的几种：
- 子模块的远端被重置过，或历史被force push过，父仓库指向的commit在远端已经不存在；
- 本地的子模块对象库不完整，缺少某些对象，导致update时找不到那个commit；
- 子模块的url配置错误，拉取的是另一个仓库，那个仓库里根本没有这个commit。
排查手段也直接：先看.gitmodules里的url和父仓库指向的commit是否处于对应远端历史中。
打开父仓库查看子模块指针：
bash复制git ls-tree HEAD config/shared
运行结果会显示类似：
code复制160000 commit 1ab44e2c8f01a97d1e2d8c0ab3e1f5 config/shared
然后手动进入子模块目录，看拉下来的远端里是否能找到这个提交：
bash复制cd config/shared
git cat-file -t 1ab44e2c8f01a97d1e2d8c0ab3e1f5
如果返回commit，说明对象在；如果报错说无法解析，说明这个commit在本地对象库中不存在。
这时候可以强制拉取远端所有对象：
bash复制git fetch origin
如果远端force push导致旧commit被清理，fetch也无法找回。真遇到历史改写的情况，解决方式更偏流程：由子模块维护者找到包含正确内容的另一个commit，再在父仓库更新指针；如果旧commit在某个tag或reflog里还存着，也可以直接指定它。
4.2 detached HEAD到底要不要管
当你执行git submodule update之后，子模块通常处于detached HEAD状态。很多人一看到HEAD detached就慌，以为切坏了分支。其实这只是说明你没有处于一个命名分支上，你的HEAD直接指向某个具体commit。
在这个状态下，你可以编译、可以看代码，也可以commit，但commit完会处于一个游离的状态，下次再执行git submodule update，你的提交可能因为不在任何分支上而变得难以找回。
更好的做法是：如果你要在子模块里做正式开发，先git checkout main或某个feature分支，再提交推送；如果你只是临时看某个版本的代码，保持在detached HEAD也无所谓。
如果你的目标是“锁定在某个发布版本的commit，不打算再修改”，detached HEAD反而是最精确的。但要注意提交后引用父仓库的行为。
4.3 子模块目录显示“modified”但你没改任何东西
这种情况经常出现。在父仓库里执行git status，提示config/shared有修改，但进到子模块里，git status又什么都没显示。
原因通常是父仓库记录的commit和你当前子模块检出commit不一致，可能来自：
- 你执行了
git submodule update --remote，把子模块拉新了，但父仓库索引还没重新记录； - 某次切分支动作改变了子模块检出点，但父仓库索引没有自动更新；
- 子模块里有Untracked文件或未提交的本地修改。
处理方式首先看差异：
bash复制git diff config/shared
如果diff里是“Subproject commit old..new”，说明是两个commit号不同；进入子模块执行git log -1，看当前HEAD和父仓库期望的commit差多少。如果只是想忽略这些变化，可以执行：
bash复制git submodule update
让子模块回到父仓库记录的状态。如果想把子模块新状态更新到父仓库索引，则执行：
bash复制git add config/shared
但要清醒地意识到，这一步其实在“变更子模块锁定版本”，不是单纯清理脏状态。
4.4 多人协作：submodule分支和权限冲突
在多团队协作时，submodule还容易暴露出权限边界问题。如果A团队拥有ui-kit仓库的写权限，B团队只是使用方，B团队在本地子模块目录里可以随便改代码，但推到ui-kit远端时大概率会被拒绝。
所以协作流程上要注意：
- 使用方可对子模块做本地定制，但这些改动如果要长期化，必须提PR给拥有方的团队，由他们合入后，再在父仓库更新指针；
- 如果子模块被多个父级仓库引用，尽量保证更新是对外“兼容”的，不要动不动force push或删除远端历史；
- 当几个父仓库同时需要bump子模块版本时，建议先在子模块仓库发布release tag，再逐一升。
push不上去的另一个常见原因是用的协议不匹配。比如clone时走的是HTTP，但你在另一个机器上配置的remote地址是SSH，本地提交要push时才发现没有写权限。检查办法：
bash复制git remote -v
在子模块目录里查看remote地址是必要的，别拿父仓库的remote地址来猜。
4.5 submodule与CI/CD工具链的配合
还有一次，我的一位同事在CI里明明执行了git submodule update --init --recursive，却总是失败。后来排查发现CI机器上拉取代码时用的是GIT_LFS_SKIP_SMUDGE=1环境变量和其他检查并没问题，真正原因是CI里的clone命令没有加--recursive参数，而后面的update又因为某些子模块URL不是本环境能够访问的SSH而失败。
在CI管道里如果子模块使用私有仓库，需要注意几点：
- 使用统一的拉取凭据，推荐HTTPS + access token或SSH deploy key；
- 明确使用
git submodule update --init --recursive，不要只update不init； - 如果子模块的上游经常变更，还可以考虑在CI里用
--remote来跟随最新，但那时候要在流水线里自行固定commit，否则构建的每次结果可能不稳定。
CI构建最怕隐性依赖。你本地能编译不代表CI能编译，原因常常就是CI机器没有子模块的拉取权限。
4.6 特殊字符与中文目录名的问题
如果你在Windows上使用submodule，遇到中文路径或文件名带着空格的情况，控制台经常显示转义别扭。这不是submodule本身问题，而是核心的quotepath默认设置造成的。想看到正常的UTF-8中文路径：
bash复制git config --global core.quotepath false
这条配置只影响显示，不影响实际存储。但很多人在网上看到前面说的-c core.quotepath=false参数，不知道是干这个的，这里顺手解释清楚。
同时，Windows上如果子模块路径非常深，还有可能达到Windows路径长度上限。解决办法是开启Git的longPaths支持：
bash复制git config --system core.longpaths true
但这个要管理员权限，而且尽量在安装Git时就处理好。
5. 选型判断：submodule不是银弹，但在这些场景很香
5.1 submodule vs Git subtree
写submodule的博客里绕不开另一个Git原生方案——subtree。
subtree的思想和submodule相反：它把子仓库的内容直接复制进父仓库维护，并与子仓库的历史通过合并策略关联。用git subtree add添加、git subtree pull拉取上游更新、git subtree push把本地的子目录修改推回源仓库。
两者最关键的区别在于：
- submodule是“父仓库只存指针”，克隆父仓库之后必须额外执行update才能拿到子模块内容；
- subtree是“父仓库存全量文件副本”，克隆完父仓库就什么都有了，不需要额外的远程依赖。
如果你们内部服务器或部署环境访问不到原始子仓库、或者不想让使用方关心“初始化子模块”这一步骤，subtree可能体验更好。
但subtree也有比较麻烦的点：当子仓库和父仓库同时修改同一目录时，合并冲突会非常拧巴；而且git subtree pull本质是一次复杂的merge，历史会被注入大量merge commit，时间久了仓库历史会比价杂乱。
两个方案怎么选？我的经验是：如果共享内容修改频率相对低，使用方更需要稳定的“快照版本”，submodule合适；如果共享内容经常被使用方就地改动，并且改动需要返给上游，subtree会自然一点，但你要能接受它的历史噪音。
5.2 submodule vs 包管理依赖
很多语言都提供了成熟的依赖管理工具，现代前端有npm/pnpm/yarn，Java有Maven/Gradle，Python有pip/Poetry。如果公共库最终能以包的形式被使用，很多时候用包管理器比submodule要舒服得多。
包管理器的优点是版本语义化清晰、lockfile可以锁定传递依赖、构建工具天然支持拉取和缓存。但submodule的使用场景是“代码级共享”，不是“产物级共享”。
比如：
- 多个微服务共享一套OpenAPI定义文件，它们需要去源仓库拿到最新的yaml文件直接生成代码；
- 多个项目共享一套CI编排脚本或基础配置文件；
- 你需要把某个项目作为另一个项目的“独立子集”包含进来，而并不想把它打成语言包发布。
这类场景中，submodule是直接指向“活的源码仓库”，天然更适合。
5.3 我的选型建议
结合我做技术管理踩过的坑，给大家一个判断清单：
- 如果被引用方需要像SDK一样发版本，优先考虑包管理器，不要硬上submodule；
- 如果共享内容只是“组织内的模板/配置文件”，且变更频率不高，submodule完全够用；
- 如果多个团队同时活跃修改共享内容，先解决职责归属问题，再考虑submodule/subtree；
- 如果父仓库需要及时且稳定地锁定一份代码，submodule能帮你把版本记录在主仓库里；
- 如果子模块数量较多且嵌套较深，最好写一个脚本或走CI，不要让每个人手动去敲一串命令。
我也不建议一上来就把所有子目录都拆成submodule。拆模块是要付出协作成本的，拆得太碎，反而每个仓库都在频繁更新，父仓库的提交历史会变成一堆版本号变化记录，可读性很差。
写在最后
我做了这么久Git相关的支持，发现真正让人头疼的往往不是submodule命令记不住，而是不理解“指针”和“内容”的边界。只要想清楚一点——父仓库保存的不是子模块代码，而是子模块某次提交的id——几乎所有操作都能推理出来。
最后分享一个小沉淀下来的习惯：对于使用submodule的项目，我会在根目录放一个.gitmodules变更历史和一份README，里面写明“子模块依赖的url、维护负责人、升级流程”，哪怕将来这个项目换人维护，新人不会对着报错手足无措。Git submodule可能初看不够直观，但一旦把更新流程固化进团队规范，它反而是多仓库协作里最稳定、最透明的那一环。