在开发一个较大的项目时，经常会遇到需要引用其他独立项目的情况。比如你正在做一个公司官网，其中的支付功能是由另一个团队维护的独立仓库。这时候直接复制代码显然不现实，更新和同步会变得非常麻烦。Git子模块（Submodule）就是为解决这类问题而生的。
什么是Git子模块
Git子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。它保留了两个项目的独立性，同时又能在一个主项目中引用并管理它的版本。换句话说，你可以在自己的项目里“嵌入”别人的项目，并且还能控制用的是哪个版本。
添加一个子模块
假设你有一个主项目叫 my-website，现在需要引入一个叫 common-utils 的工具库作为子模块。操作很简单：
git submodule add https://github.com/user/common-utils.git libs/common-utils执行后，你会在项目里看到多了一个 libs/common-utils 目录，同时根目录下生成一个 .gitmodules 文件，记录了子模块的地址和路径。
克隆包含子模块的项目
当你把项目分享给别人，对方克隆时不会自动下载子模块内容。如果只运行普通的 clone 命令：
git clone https://github.com/user/my-website.git会发现 libs/common-utils 目录是空的。正确的做法是初始化并更新子模块：
git submodule init
git submodule update或者一步到位：
git clone --recurse-submodules https://github.com/user/my-website.git更新子模块内容
子模块默认指向的是某个特定提交，而不是自动跟随远程更新。如果你希望升级到最新版本，需要进入子模块目录手动拉取：
cd libs/common-utils
git pull origin main然后回到主项目提交变更，这样其他人就能同步到你更新后的子模块版本。
子模块的常见坑点
新手容易忽略的一点是“游离头指针”状态。当你进入子模块却没有切换到具体分支时，它可能处于 detached HEAD 状态，这时做的修改如果不小心提交了，很难被追踪。为了避免这种情况，建议进入子模块后先确认是否在正确的分支上：
git checkout main还有一种情况是删除子模块。不能直接删文件夹，得先编辑 .gitmodules 和 .git/config，再运行 git rm 命令清理缓存，否则会留下残留记录。
适用场景举例
比如你是个前端开发者，手头有个电商项目，其中登录组件由安全团队统一维护。你们不想每次更新都手动复制粘贴，又担心直接合并代码造成混乱。用子模块就能完美解决——你的项目引用他们的组件仓库，他们一发布新版本，你就可以选择是否升级，既灵活又可控。
对于团队协作频繁、模块职责分明的项目来说，Git 子模块虽然稍微增加了一点操作成本，但带来的版本隔离和依赖清晰化，远比这点学习成本有价值。