Git submodule

Git submodule

项目的版本库在某些情况下需要引用其他版本库中的文件，例如有一套公用的代码库，可以被多个项目调用，这个公用代码库能直接放在某个项目的代码中，而是要独立为一个代码库，那么其他要调用公用的代码库该如何处理？分别把公用的代码库拷贝到各自的项目中会造成冗余，丢弃了公共代码库的维护历史，这些显示不是好的办法，现在要了解的git子模组(git submodule)就解决了这个问题。

Git 子模块功能允许你将一个Git仓库当作另外一个Git仓库的子目录。这允许你克隆另外一个仓库到你的项目中并且保持你的提交相对独立。

 

为当前工程添加submodule，命令如下：

 

gitsubmodule add 仓库地址路径

准备工作

1 2 3 4 5

git --git-dir=lib1.git init --bare git --git-dir=lib2.git init --bare git --git-dir=project1.git init --bare git --git-dir=project2.git init --bare

 

创建两个项目 和两个lib 库

为pro1 添加lib1 和lib 2

 

好了，到目前为止我们已经使用git submodule add命令为pro1成功添加了两个公共类库（lib1、lib2），查看了当前的状态发现添加了一个新文件(.gitmodules)和两个文件夹(libs/lib1、libs/lib2)；那么新增的.gitmodules文件是做什么用的呢？我们查看一下文件内容便知晓了

.gitmodules记录了每个submodule的引用信息，知道在当前项目的位置以及仓库的所在

好的，我们现在把更改提交到仓库。

 

2.3 Clone带有Submodule的仓库

模拟开发人员B…

看到submodules的状态是hash码和文件目录，但是注意前面有一个减号：-，含义是该子模块还没有检出。

 

OK，检出pro3的submodules……

 

 

看到submodules的状态是hash码和文件目录

 

2.3 修改Submodule

我们在开发人员B的项目上修改Submodule的内容。

先看一下当前Submodule的状态：

为什么是Not currently on any branch呢？不是应该默认在master分支吗？

Git对于Submodule有特殊的处理方式，在一个主项目中引入了Submodule其实Git做了3件事情：

• 记录引用的仓库
• 记录主项目中Submodules的目录位置
• 记录引用Submodule的commit id

在project1中push之后其实就是更新了引用的commit id，然后project1-b在clone的时候获取到了submodule的commit id，然后当执行git submoduleupdate的时候git就根据gitlink获取submodule的commit id，最后获取submodule的文件，所以clone之后不在任何分支上；但是master分支的commit id和HEAD保持一致。

现在我们要修改lib1的文件需要先切换到master分支：

 

 

 

 

在主项目中修改Submodule提交到仓库稍微繁琐一点，在git push之前我们先看看pro3状态

 

libs/lib1 (newcommits)状态表示libs/lib1有新的提交，这个比较特殊，看看pro3的状态：

 

从状态中可以看出libs/lib1的commit id由原来的9eb0da731371c30de43a8a3af6d7ad0e0d8c0051更改为2d3289c65b67df2f548595dec500f533cec2fdda

注意：如果现在执行了git submodule update操作那么libs/lib1的commit id又会还原到9eb0da731371c30de43a8a3af6d7ad0e0d8c0051，

 

这样的话刚刚的修改是不是就丢失了呢？不会，因为修改已经提交到了master分支，只要再git checkout master就可以了。

现在可以把libs/lib1的修改提交到仓库了：

现在仅仅只完成了一步，下一步要提交pro3引用submodule的commit id：

 

OK，大功高成，我们完成了Submodule的修改并把libs/lib1的最新commit id提交到了仓库。

接下来要看看pro1怎么获取submodule了。

更新主项目的Submodules

好的，让我们先进入pro1目录同步仓库：

 

我们运行了git pull命令和git status获取了最新的仓库源码，然后看到了状态时modified，这是为什么呢？

我们用git diff比较一下不同：

 

从diff的结果分析出来时因为submodule的commit id更改了，我们前面刚刚讲了要在主项目更新submodule的内容首先要提交submdoule的内容，然后再更新主项目中引用的submodulecommit id；现在我们看到的不同就是因为刚刚更改了pro3的submodule commit id；好的，我来学习一下怎么更新pro1的公共类库。

 

如果，出现下面画面说明子模块没有更新

因为子模块是在pro1中引入的，git submodule add  /repos/lib1.git libs/lib1命令的结果，操作之后git只是把lib1的内容clone到了pro1中，但是没有在仓库注册，可以查看./git/config中的内容

 

 没有注册没有submodule 的节点  我们说过git submodule init就是在.git/config中注册子模块的信息，下面我们试试注册之后再更新子模块：      

git submoudleinit

Git submoduleupdate

来更新子模块。

 

更新后我们看看

 

上面的结果足以证明刚刚的推断，所以记得当需要更新子模块的内容时请先确保已经运行过git submodule init。

 

 

为pro2添加lib1和lib2

 

 

 

 

 

修改lib1和lib2并同步到project1和project2

假如开发人员C同时负责pro1和pro2，有可能在修改pro1的某个功能的时候发现lib1或者lib2的某个组件有bug需要修复，这个需求多模块和大型系统中经常遇到，我们应该怎么解决呢？

假如我的需求如下：

·        在lib1中添加一个文件：README，用来描述lib1的功能

·        在lib2中的lib2.txt文件中添加一写文字：学习Gitsubmodule的修改并同步功能

 

前面提到过现在仅仅只完成了一部分，我们需要在pro2中再更新lib1的commitid：

 

 

在lib2中的lib2.txt文件添加文字

 

 

同步pro2的lib1和lib2的修改到pro1

 

看看上面的结果对吗？为什么lib1和lib2更新了但是没有显示new commits呢？说到这里我记得刚刚开始学习的时候真得要晕死了，Git跟我玩捉迷藏游戏，为什么我明明提交了但是从pro1更新不到任何改动呢？

先看看当前(project1和project2)的submodule状态：

 

pro2 的状态，也就是我们刚刚修改后的状态

pro1 的状态，等待更新submodules

两个项目有两个区别：

·        commit id各不相同

·        libs/lib1所处的分支不同

更新pro1的lib1和lib2改动

我们还记得刚刚在pro2中修改的时候把lib1和lib2都切换到了master分支，目前pro1中的lib1不在任何分支，我们先切换到master分支

 

果不其然，我们看到了刚刚在pro2中修改的内容，同步到了pro1中，当然现在更新了pro1的lib1，commit id也会随之变动：

 

 

现在最新的commitid和pro2目前的状态一致，说明真的同步了；好的，现在可以使用相同的办法更新lib2了

 

更新pro1的submodule引用

在上面我们更新了pro1的lib1和lib2的最新版本，现在要把最新的commitid保存到project1中以保持最新的引用。

 

 

 

 

小结

使用submodules 初始化项目的时候要把每个submodule 都切换到指定分支。

以后每次更新submodule 后先推送到submodule的远程分支。再更新主module里面的 submodule的commit id。最后推送到远程分支。