submodule使用笔记

git submodule
子模块允许你将一个 Git 仓库作为另一个 Git 仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中，同时还保持提交的独立。

比如我们想抽象出一个组件库供多个项目使用

git submodule add <子模块git地址> <存放的文件名>

会生成: .gitmodules 和 子模块文件夹

.gitmodules 文件保存了项目 URL 与已经拉取的本地目录之间的映射，这样就能知道子模块在哪获取。如果有多个子模块，该文件中就会有多条记录。

子模块文件夹只存子项目的commit id，就能指定到对于的git header上, 父项目的git并不会记录Submodule的文件变动，它是按照commitid指定Submodule的git header

当你不在那个目录中时，Git 并不会跟踪它的内容， 而是将它看作子模块仓库中的某个具体的提交。

注意的是，这两个文件也像 .gitignore 文件一样受到（通过）版本控制。 它会和该项目的其他部分一同被拉取推送。

克隆含有子模块的项目
克隆一个含有子模块的项目时，默认会包含该子模块目录，但其中还没有任何文件，是空目录。 必须运行：

git submodule init 用来初始化本地配置文件

git submodule update 则从该项目中抓取所有数据并检出父项目中列出的合适的提交。

合成一步就是： git submodule update --init

如果还要初始化、抓取并检出任何嵌套的子模块：git submodule update --init --recursive

或者在克隆的时候加上参数： git clone --recurse-submodules

它就会自动初始化并更新仓库中的每一个子模块， 包括可能存在的嵌套子模块。

修改submodule
进入submodule目录里修改后add 、commit 、push到远程服务器，然后要回到父目录，提交submodule在父项目中的改动（submodule commit id 会更新），再push

坑：子模块的分支默认不是master，也不会切到任何branch
当我们运行 git submodule update 从子模块仓库中抓取修改时， Git 将会获得这些改动并更新子目录中的文件，但是会将子仓库留在一个称作“游离的 HEAD”的状态。 这意味着没有本地工作分支（例如 “master” ）跟踪改动。 如果没有工作分支跟踪更改，也就意味着即便你将更改提交到了子模块，这些更改也很可能会在下次运行 git submodule update 时丢失。

因此，在修改前先进入子模块，然后切换到需要的分支(eg. git checkout master)，然后再对子模块做修改、提交。

## **注意**

- 拉取时, 先拉主项目, 再拉子项目
- 推送时, 先推子项目, 再推主项目
- 拉取时不要忘记更新子项目，推送时不要忘记更改主项目中引用的子项目 `commitid`
- 覆盖文件或删除文件有时会导致在子项目目录里操作不了子项目的git

Leanote's Blog

Navigation

Recent Posts

Friend Links