若是项目分的模块比较多,并且对每一个模块须要独立管理的话,子模块就派上用场了。每个子模块都是一个独立的git仓库,有点相似于svn的外链。下面简单讲一下在现有的git仓库里添加子模块的配置。git
在主项目中添加子模块程序员
git submodule add git@gitlab.code.anzogame.com:octopus/L1.git
这就完啦?对,就这么简单,回车后就会自动clone子模块的最新代码下来,并命名为L1,固然也能够重命名,只须要在命令后面跟上须要重命名的名字便可。svn
clone带子模块的项目,前提是对子模块的仓库是有相应权限的gitlab
//方式一 git clone --recursive <url> //方式二 git clone <url> git submodule init git submodule update
其实主项目只是保存了一个子模块的地址和对应的commit号,以下图:url
**注意这里只指向子模块仓库的某一个版本,通常状况下并不会特别指向某一个分支,clone
代码的时候是把这个版本的代码clone
下来了(不必定的子模块最新的代码)。**以下图:指针
不在分支上的本地工做区是不能提交同步代码的,因此这里若是后续须要对子模块修改提交并同步的话,是须要手动切换都某一个分支的,以下图:code
对子模块内容作修改后的提交同步
注意看红色L1后面的状态,
untracked content
的意思是L1子模块里有内容修改,而且这个修改并无被加入版本管理里。it
commit
,主项目里的子模块的commit
号就会随之改变,再看一下状态: 此时L1后面跟的是
new commits
,这表明主项目所保存的子模块的版本号已经改变了,你须要将这个版本号在主项目也提交才行,否则就会出现不匹配的状态。版本管理
cd
进入子模块进行push
,同步真正修改的内容到远程仓库,而后再回到主项目push
,就是同步推送主项目指向子模块的commit
号到远程仓库。这里有个坑,你们刚开始的时候会常常遇到。甲同窗
对L1子模块进行了修改而且同步到远程仓库了,可是没有提交主项目对这个子模块的版本号,这时乙同窗
对子模块L1进行了单独的更新,这个时候问题就出现了,乙同窗
在主项目git status
查看状态的时候会出现L1是红色的,而且是[new commits]状态,**这是由于乙同窗
主项目里L1子模块的版本号已经变了,子模块的版本号只由当前子模块的最新commit号决定,也就是HEAD指针指向的commit号。**因此这个时候须要请甲同窗
提交一下,若是不提交问题也不大,乙同窗
本身提交上去,只是这个时候甲同窗
再提交会出现L1的这commit号冲突,由于对于主项目来讲这个子模块版本号两我的都作了修改,可是这个能够不解决,由于这个commit号是手动改不了了,也就是说不用解决这个冲突,保持最新就好。可是冲突老是你们不想遇到的,因此在对子模块有修改的时候尽可能都把对应的主项目的版本号也提交上去,这才是最正确的操做。
多个子模块简便操做
当遇到一个功能须要多个子模块都同时作了修改,那么相应的对这几个子模块都要作一次提交,这个时候若是一个一个的cd进去再提交同步就会是个很是麻烦的事情,程序员都是懒得。这个时候用下面这个命令就能够完美解决:
git submodule foreach "<git command>"
他会对子模块一个一个的执行尖括号里的命令,例如git submodule foreach "git push"
讲完了!