Fork me on GitHub

Git_Submodules

发表于 | | 阅读次数:

        本例采用两个项目以及两个公共类库演示对submodule的操作。因为在一些资料或者书上的例子都是一个项目对应1~N个lib，但是实际应用往往并不是这么简单。

准备环境

1
创建需要的本地仓库：
2
初始化工作区：
3

初始化项目

初始化project1:

4
我在此用的是相对路径，若有问题请用绝对路径。
5

初始化project2:

7
8
9
10

初始化公共类库

初始化公共类库lib1：

11
12

初始化公共类库lib2:

13
14

为主项目添加Submodules

为project1添加lib1和lib2

15
16

查看已下公共类库的内容

17
好了，到目前为止我们已经使用git submodule add命令为project1成功添加了两个工共类库(lib1、lib2)，查看了当前的状态发现添加了一个新文件.gitmodules和两个文件夹libs/lib1、libs/lib2，那么新增的.gitmodules是做什么用的呢？我们查看以下文件内容便知晓了。
18
原来如此，.gitmodules记录了每个submodule的引用信息，知道在当前项目的位置以及仓库的所在。
好的，我们现在把更改提交到仓库。
19
        假如你是第一次引入工共类库的开发人员，那么项目组的其他成员怎么Clone带有Submodule的项目呢，下面我们再clone一个项目讲解如何操作。

Clone带有Submodule的仓库

模拟开发人员B…
20
看到submodules的状态是hash码和文件目录，但是注意前面有一个减号，含义是该子模块还没有检出。
OK，检出project1-b的submodules…
21
读者可以查看: .git/config文件的内容，最下面有submodule的注册信息！
验证一下类库的文件是否存在：
22
上面的两个命令(git submodule init & update)其实可以简化，后面会讲到!

修改Submodule

我们在开发人员B的项目上修改Submodule的内容。
先看一下当前Submodule的状态：
23
我们可以看到HEAD不指向分支。
Git对于Submodule有特殊的处理方式，在一个主项目中引入了Submodule其实Git做了3件事：

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

在project1中push之后其实就是更新了引用的commit id,然后project1-b在clone的时候获取到了submodule的commit id，然后当执行git submodule update的时候git就根据gitlink获取submodule的commit id，最后获取submodule的文件，所以clone之后不在任何分支上；但是master分支的commit id和HEAD保持一致。
现在我们要修改lib1的文件需要先切换到master分支：
24
在主项目中修改Submodule提交到仓库稍微繁琐一点，在git push之前我们先看看project1-b的状态:
25
libs/lib1(new commits)状态表示libs/lib1有新的提交，这个比较特殊，看看project1-b的状态:
26
从状态中可以看出libs/lib1的commit id由原来的3ee623ea26cd10ec58c1f1fa4f5869e488e0cfc1更改为d176f81129a28e5cb25c2b285818ed0202be7e58
注意：如果现在执行了git submodule update操作，那么libs/lib1的commit id又会还原到3ee623ea26cd10ec58c1f1fa4f5869e488e0cfc1，这样的话刚刚的修改是不是就丢死了呢？不会，因为修改已经提交到了master分支，只要再git checkout master就可以了。
现在可以把libs/lib1的修改提交到仓库了。
27
现在仅仅只完成了一步，下一步要提交project1-b引用submodule的commit id：
28
OK，大功告成，我们完成了Submodule的修改并把libs/lib1的最新commit id提交到了仓库。
接下来要看看project1怎么获取submodule了。

更新主项目的Submodules

好的，让我们进入project1目录同步仓库：
29
30
我们运行了git pull命令和git status获取了最新的仓库源码，然后看到了状态是modified，这是为什么呢？
我们用git diff比较一下不同:
31
从diff的结果分析出来是因为submodule的commit id更改了，我们前面刚刚讲了要在主项目更新submodule的内容，首先要提交submodule的内容，然后再更新主项目中引用的submodule commit id；现在我们看到的不同就是因为刚刚更改了project1-b的submodule commit id；好的，我们来学习下怎么更新project1的公共类库。
32
git submodule update是更新子模块仓库。
如果没有更新，是因为子模块是在project1中引入的，git submodule add repos/lib1.git libs/lib1命令的结果，操作之后git只是把lib1的内容clone到了project1中，但是没有在仓库注册。需要输入git submodule init, 再进行git submodule update 在仓库注册后的结果如下：
33
34
上面的结果足以证明刚刚的推断，所以记得当需要更新子模块的内容时请先确保已经运行过git submodule init。

为project2添加lib1和lib2

这个操作对于读到这里的你来说应该是很熟的了：
35
36
37
我们一次执行了添加submodule并commit和push到仓库，此阶段任务完成。

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

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

  • 在lib1中添加一个文件：README，用来描述lib1的功能。
  • 在lib2在的lib2-features文件中添加一些文字：学习Git submodule的修改并同步功能

在lib1中添加一个文件：README

38
39
前面提到过现在仅仅只完成了一部分，我们需要在project2中再更新lib1的commit id：
40
我们暂时不push到仓库，等待和lib2的修改一起push。

在lib2中的lib2-features文件中添加文字

41
42
43
44
45
46

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

既然project1和project2属于同一个风格，或者调用同一个功能，要让这两个(可能几十个)项目保持一致。
47
        看看上面的结果对吗？为什么lib1和lib2更新了但是没有显示new commits呢？为什么我明明提交了但是从project1更新不到任何改动呢？
        帮大家分析一下问题，不过在分析之前先看看当前(project1和project2)的submodule状态：
48
两个项目有两个区别：

  • commit id 各不相同
  • libs/lib1所处的分支不同

更新project1的lib1和lib2改动

        我们还记得刚刚在project2中修改的时候把lib1和lib2都切换到了master分支，目前project1中的lib1不在任何分支，我们先切换到master分支。
49
50
        果不其然，我们看到了刚刚在project2中修改的内容，同步到了project1中，当然现在更新了project1的lib1，commit id也会随之变动。
51
52
        现在最新的commit id和project2目前的状态一致，说明真的同步了；好的，现在可以使用相同的方法更新lib2了。
53

更新project1的submodule引用

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

更新project1-b项目的子模块(使用脚本)

56
57
        Git提示lib1和lib2有更新内容，这个判断的依据来源于submodule commit id的引用。
        现在怎么更新呢？难道还是像project1中那样进入子模块的目录然后git checkout master，接着git pull？
        而且现在仅仅才两个子模块、两个项目，如果在真是的项目中使用的话可能几个到几十个不等，再加上N个submodule，自己算一下要怎么更新多少个submodule？
工欲善其事，必先利其器。写一个脚本代替手动任务。

牛刀小试

58
我们通过分析.gitmodules文件得出子模块的路径，然后就可以根据这些路径进行更新。

上路

59
把下面的脚本复制到bin/update-submodules.sh中

1
2
3
4
5
6
7
8
9
#!/bin/bash
grep path .gitmodules | awk '{ print $3 }' > /tmp/study-git-submodule-dirs
 
# read
while read LINE
do
    echo $LINE
    (cd ./$LINE && git checkout master && git pull)
done < /tmp/study-git-submodule-dirs

解释下上面的脚本执行过程：

  • 首先把子模块的路径写入到文件tmp/sutdy-git-submodule-dirs中；
  • 然后读取文件中的子模块路径，一次切换到master分支(修改都是在master分支上进行的)，最后更新最近改动。

2018-08-18更新

一个命令就可以代替上面的bin/update-submodules.sh的功能。

1
2
<pre class="brush:shell">git submodule foreach git pull
</pre>

此命令与脚本一样，循环进入(enter)每个子模块的目录，然后执行foreach后面的命令。

该后面的命令可以任意的，例如git submodule foreach ls -l可以列出每个子模块的文件列表。

体验工具带来的便利

60
添加执行权限
61
62
更新之后的两个变化：

  • git submodule的结果和project2的submodule commit id保持一致；
  • project1-b不再显示new commits了。

现在可以把工具添加到仓库了。
63

新员工加入团队，一次性clone项目和Submodule

一般人使用的时候都是使用如下命令：

1
2
3
git clone ../repos/foo.git
git submodule init
git submodule update

新员工不耐烦了，嘴上不说但是心里想，怎么那么麻烦？
上面的命令简直弱爆了，直接一行命令搞定：

1
git clone --recursive ../repos/foo.git

recursive参数的含义：可以在clone项目时同时clone关联的submodules。

使用一键方式克隆project2

64
舒服……

移除Submodules

我们从project1.git克隆一个项目用来练习移除submodule：
65

Step by

1、删除git cache和物理文件夹
66
67
2、删除.gitmodules的内容(或者整个文件)
因为本例只有两个子模块，直接删除文件：
68
如果仅仅删除某一个submodule，那么打开.gitmodules文件编辑，删除对应submodule配置即可。
3、删除.git/config的submodule配置
源文件：
69
删除后：
70
4、提交更改
71
72

Your support will encourage me to continue to create!