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