2.0 KiB
主仓库和子仓库确实是独立的 Git 仓库，各自有自己的提交历史。但关键在于： 主仓库需要记录"使用子模块的哪个版本"
工作原理 当你在主仓库中添加 submodule 时，主仓库实际上存储的是： 子模块的远程仓库 URL（存在 .gitmodules 文件中） 子模块的特定 commit SHA（这是关键！） 你可以理解为主仓库中有一个"指针"，指向子模块的某个具体 commit。 为什么需要更新引用？ 看这个场景：
子模块当前在 commit abc123
主仓库记录：thingsboard-client-demo -> abc123
你修改了子模块代码
cd thingsboard-client-demo git commit -m "新功能" # 产生新 commit def456 git push
此时：
- 子模块远程仓库：最新是 def456
- 主仓库记录：仍然是 abc123 ❌
如果不更新主仓库的引用，会发生什么？ 其他团队成员克隆主仓库后，执行 git submodule update 他们会得到 abc123 版本的子模块 他们看不到你的新功能（def456）！ 更新引用的作用 cd /Users/sunpeng/workspace/hyf git add thingsboard-client-demo # 更新指针：abc123 -> def456 git commit -m "Update submodule" git push 这一步是在告诉主仓库："现在请使用子模块的 def456 版本"。 类比理解 可以把它想象成： 子仓库 = 一个独立的软件包（比如 npm 包） 主仓库 = package.json 文件 当你更新了软件包的代码并发布新版本后，你还需要在 package.json 中更新版本号，告诉项目"请使用新版本"。 // 类似于 { "dependencies": { "thingsboard-client-demo": "1.0.0" // 旧版本 "thingsboard-client-demo": "1.1.0" // 需要手动更新到新版本 } } 总结 主仓库和子仓库是独立的，但主仓库需要明确记录使用子仓库的哪个版本。这样可以： 保证团队成员获得一致的代码版本 支持版本回退（可以回到使用旧版本子模块的状态） 避免子模块"自动更新"导致的不可预期问题 这就是为什么修改子模块后，需要在主仓库中更新引用的原因。