48 lines
2.0 KiB
Markdown
48 lines
2.0 KiB
Markdown
主仓库和子仓库确实是独立的 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" // 需要手动更新到新版本
|
||
}
|
||
}
|
||
总结
|
||
主仓库和子仓库是独立的，但主仓库需要明确记录使用子仓库的哪个版本。这样可以：
|
||
保证团队成员获得一致的代码版本
|
||
支持版本回退（可以回到使用旧版本子模块的状态）
|
||
避免子模块"自动更新"导致的不可预期问题
|
||
这就是为什么修改子模块后，需要在主仓库中更新引用的原因。 |