[[top]]

git submodules 子模块

如果想要在一个 git 我的项目中蕴含有其余 git 我的项目 (比方一些根底框架库, 组件库，共用代码等)，能够应用git submodules 进行治理。本文就 git submodules 罕用用法做一些记录，浏览前能够先查看官网文档), 指令详解).

个人感觉: git 子模块跟 tag 十分像。

git 子模块初始化

如果想要为以后模块增加一个子模块，能够执行 add 指令 :

git submodule add <repository> [<path>]

如:

git submodule add https://github.com/hscfapps/vue-app-plus-inner.git

它会在以后我的项目下创立一个 vue-app-plus-inner 的目录，该目录就用于寄存指标库的代码。如果你须要改一下寄存子 git 我的项目目录名，能够:

git submodule add https://github.com/hscfapps/vue-app-plus-inner.git source-app

默认会拉去指标库的 master 分支，如果你要拉去指定分支，能够在执行命令行时增加选项:

git submodule -b release add https://github.com/hscfapps/vue-app-plus-inner.git

这样就会拉去 release 分支。

执行指令后，还会生成一个 .gitmodules 文件，该文件用于寄存 git submodules 的一些配置，能够间接该这外面的配置，但不平安，更加倡议通过提供的 git submodules 批改一些配置。

具体能够查看 .gitmodules 文件阐明)。

如果你是克隆一个含有子模块的 git 我的项目，默认克隆下来, 会蕴含 .gitmodules 文件和子模块目录名，然而目录文件夹下没有任何内容，须要执行:

git submodule init

git submodule update

这个时候就能将子模块的代码拉去下来了。

下面有一个简便计划，在克隆时增加 --recursive 选项:

git clone --recursive https://github.com/chaconinc/DbConnector

该我的项目中的子模块以及嵌套子模块都会被初始化，不须要在去执行 init, update 操作了

update用于跟新代码，但只会跟新代码到以后的我的项目中保留的子模块的 commit(这在官网文档中有阐明, git 会将子模块视为有非凡的文件, 记录它的 commit，而不是把他作为一个目录). 但 git 服务器上通常会比本地多几次提交，所以能够增加--remote 选项，来强制将子模块更新到以后分支最新的提交:

git submodule update --remote

如果子模块在本地有批改，那么拉取代码就会失败，你能够指定:

git submodule update --remote --merge

就会在拉去下来后跟本地合并。

git submodule update --remote其实相当于在每个子模块目录下执行 git pull 操作，且是将服务器上每个分支的代码都更新了下来。

还须要留神一点的时, 执行git submodule update，会对所有的子模块都失效，如果你须要只对某一个子模块失效，能够

git submodule update <options>  moduleNmae

至于何时应用 git submodule update --remote，取决于以后子模块是固定版本升级还是采取主动降级策略，如果是固定版本升级，只有在 git 我的项目中须要降级子模块时，才执行git submodule update --remote(其实更好的方法时进入该子模块目录下，手动降级到指定的 commit，实现精准版本控制)。如果时主动降级，那么在每次变更代码时，都能够执行git submodule update --remote 将子模块降级到最新的提交，而后提交代码到服务器上。

子模块分支切换

在上文中，说过能够在初始化子模块时指定分支。在理论开发过程时，会碰到分支须要变更的需要，git submodule提供 set-branch 指令来扭转子模块的分支:

git submodule set-branch -b branchName sub-module-name

扭转之后，须要留神的是以后子模块的 commit 并没有发生变化，须要执行

git submodule update --remote

更新 commit。

所以 set-branch 指令更像是在 .gitmodules 外面将分支的配置批改一下。

发现 –default 选项不能应用，可能是我应用的形式不对。

在子模块中的代码操作

进入子模块后，就是进入了一个新的 git 库，能够执行任何 git 指令。生成新的 commit 之后，在推送到子模块的 git 服务器库之后，如果以后我的项目须要应用，还是要推送以后我的项目的最新代码。

gitsubmodule 作为版本公布器

以后 clone 一个带有子模块的 git 我的项目时，初始化子模块后，进入子模块中，执行 git status 会发现，以后子模块的 git head 处于游离状态, 指向一个 commit，跟tag 的状态十分相似。所以子模块其实记录的都是 commit 点, 跟分支没有关系，所以上文中的分支操作你都能够不须要去管他们。

当咱们须要更新一个子模块时，能够在以后我的项目中进入子模块，而后通过平时的 git 指令将子模块我的项目执行指标 commit 点，而后在 git 我的项目中提交，推送到服务器上，这样子模块就降级了(跟 tag 作为版本公布的点有点类似)。

基于 commit 而不是基于 branch 的子模块人造反对版本公布的特点。

子模块遍历执行指令

如果我的项目中有多个子模块，在执行一些操作时，须要进入每个子模块目录下执行指令，非常的典范。

git submodule提供 foreach 指令，反对在每个库中执行雷同的 git 指令:

git submodule foreach git status

或者:

git submodule foreach "git status"

嵌套子模块

在克隆我的项目时，增加选项--recursive，能够递归的初始化嵌套子模块。

另外一些 git submodules 指令反对--recursive, 也都反对对嵌套子模块操作。

删除子模块

能够首先执行:

git submodule deinit -f sub-module-name

删除全副:

git submodule deinit -f --all

而后执行:

git rm sub-module-name

如果上述操作还不能删除子模块，依照下述的步骤手动操作一遍:

• rm -rf 子模块目录 删除子模块目录及源码
• vi .gitmodules 删除我的项目目录下.gitmodules 文件中子模块相干条目
• vi .git/config 删除配置项中子模块相干条目
• rm .git/module/* 删除模块下的子模块目录，每个子模块对应一个目录，留神只删除对应的子模块目录即可
• git rm 子模块名称