submodule切换分支_Git Submodule使用完整教程

自从看了蒋鑫的《Git权威指南》之后就开始使用Git Submodule功能，团队也都熟悉了怎么使用，多个子系统(模块)都能及时更新到最新的公共资源，把使用的过程以及经验和容易遇到的问题分享给大家。

Git Submodule功能刚刚开始学习可能觉得有点怪异，所以本教程把每一步的操作的命令和结果都用代码的形式展现给大家，以便更好的理解。

1.对于公共资源各种程序员的处理方式

每个公司的系统都会有一套统一的系统风格，或者针对某一个大客户的多个系统风格保持统一，而且如果风格改动后要同步到多个系统中；这样的需求几乎每个开发人员都遇到，下面看看各个层次的程序员怎么处理：

假如对于系统的风格需要几个目录：css、images、js。

普通程序员，把最新版本的代码逐个复制到每个项目中，如果有N个项目，那就是要复制N x 3次；如果漏掉了某个文件夹没有复制…@(@#。

文艺程序员，使用Git Submodule功能，执行：git submodule update，然后冲一杯咖啡悠哉的享受着。

引用一段《Git权威指南》的话： 项目的版本库在某些情况虾需要引用其他版本库中的文件，例如公司积累了一套常用的函数库，被多个项目调用，显然这个函数库的代码不能直接放到某个项目的代码中，而是要独立为一个代码库，那么其他项目要调用公共函数库该如何处理呢？分别把公共函数库的文件拷贝到各自的项目中会造成冗余，丢弃了公共函数库的维护历史，这显然不是好的方法。

2.开始学习Git Submodule

“工欲善其事，必先利其器”！

既然文艺程序员那么轻松就搞定了，那我们就把过程一一道来。

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

2.1 创建Git Submodule测试项目

2.1.1 准备环境

创建需要的本地仓库：

初始化工作区：

2.1.2 初始化项目

初始化project1：

初始化project2：

2.1.3 初始化公共类库

初始化公共类库lib1：

初始化公共类库lib2：

2.2 为主项目添加Submodules

2.2.1 为project1添加lib1和lib2

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

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

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

假如你是第一次引入公共类库的开发人员，那么项目组的其他成员怎么Clone带有Submodule的项目呢，下面我们再clone一个项目讲解如何操作。

2.3 Clone带有Submodule的仓库

模拟开发人员B……

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

OK，检出project1-b的submodules……

读者可以查看：.git/config文件的内容，最下面有submodule的注册信息！

验证一下类库的文件是否存在：

上面的两个命令(git submodule init & update)其实可以简化，后面会讲到！

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 submodule update的时候git就根据gitlink获取submodule的commit id，最后获取submodule的文件，所以clone之后不在任何分支上；但是master分支的commit id和HEAD保持一致。

查看~/submd/ws/project1-b/libs/lib1的引用信息：

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

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

libs/lib1 (new commits)状态表示libs/lib1有新的提交，这个比较特殊，看看project1-b的状态：

从状态中可以看出libs/lib1的commit id由原来的c22aff85be91eca442734dcb07115ffe526b13a1更改为36ad12d40d8a41a4a88a64add27bd57cf56c9de2

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

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

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

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

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

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

2.4 更新主项目的Submodules

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

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

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

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

follow me……

泥马，为什么没有更新？git submodule update命令不是更新子模块仓库的吗？

别急，先听我解释；因为子模块是在project1中引入的，git submodule add ~/submd/repos/lib1.git libs/lib1命令的结果，操作之后git只是把lib1的内容clone到了project1中，但是没有在仓库注册，证据如下：

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

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

2.5 为project2添加lib1和lib2

这个操作对于读到这里的你来说应该是轻车熟路了，action：

我们依次执行了添加submodule并commit和push到仓库，此阶段任务完成。

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

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

假如我的需求如下：

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

在lib2中的lib2-features文件中添加一写文字：学习Git submodule的修改并同步功能

2.6.1 在lib1中添加一个文件：README

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

我们暂时不push到仓库，等待和lib2的修改一起push。

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

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

现在project2已经享受到了最新的代码带来的快乐，那么既然project1和project2属于同一个风格，或者调用同一个功能，要让这两个(可能几十个)项目保持一致。

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

帮大家分析一下问题，不过在分析之前先看看当前(project1和project2)的submodule状态：

两个项目有两个区别：

commit id各不相同

libs/lib1所处的分支不同

2.7.1 更新project1的lib1和lib2改动

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

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

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

2.7.2 更新project1的submodule引用

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

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

Git提示lib1和lib2有更新内容，这个判断的依据来源于submodule commit id的引用。

现在怎么更新呢？难道还是像project1中那样进入子模块的目录然后git checkout master，接着git pull？

而且现在仅仅才两个子模块、两个项目，如果在真实的项目中使用的话可能几个到几十个不等，再加上N个submodule，自己算一下要怎么更新多少个submodules？

例如笔者现在做的一个项目有5个web模块，每个web模块引用公共的css、js、images、jsp资源，这样就有20个submodule需要更新！！！

工欲善其事，必先利其器，写一个脚本代替手动任务。

2.8.1 牛刀小试

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

2.8.2 上路

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

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

首先把子模块的路径写入到文件/tmp/study-git-submodule-dirs中；

然后读取文件中的子模块路径，依次切换到master分支(修改都是在master分支上进行的)，最后更新最近改动。

2.8.3 2013-01-19更新

网友@紫煌给出了更好的办法，一个命令就可以代替上面的bin/update-submodules.sh的功能：

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

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

2.8.3 体验工具带来的便利

更新之后的两个变化：

git submodule的结果和project2的submodule commit id保持一致；

project1-b不再提示new commits了。

现在可以把工具添加到仓库了，当然你可以很骄傲的分享给其他项目组的同事。

2.9 新进员工加入团队，一次性Clone项目和Submodules

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

新员工不耐烦了，嘴上不说但是心里想：怎么那么麻烦？

上面的命令简直弱暴了，直接一行命令搞定：

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

git help 对其解释：

--recursive, --recurse-submodules

After the clone is created, initialize all submodules within, using their default settings. This is equivalent to running git

submodule update --init --recursive immediately after the clone is finished. This option is ignored if the cloned repository

does not have a worktree/checkout (i.e. if any of --no-checkout/-n, --bare, or --mirror is given)

2.9.1 使用一键方式克隆project2

舒服……

3.移除Submodule

牢骚：搞不明白为什么git不设计一个类似：git submodule remove的命令呢？

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

3.1 Step by

1、删除git cache和物理文件夹

2、删除.gitmodules的内容(或者整个文件) 因为本例只有两个子模块，直接删除文件：

如果仅仅删除某一个submodule那么打开.gitmodules文件编辑，删除对应submodule配置即可。

3、删除.git/config的submodule配置 源文件：

[core]

repositoryformatversion = 0

filemode = true

bare = false

logallrefupdates = true

[remote "origin"]

fetch = +refs/heads/*:refs/remotes/origin/*

url = /home/henryyan/submd/ws/../repos/project1.git

[branch "master"]

remote = origin

merge = refs/heads/master

[submodule "libs/lib1"]

url = /home/henryyan/submd/repos/lib1.git

[submodule "libs/lib2"]

url = /home/henryyan/submd/repos/lib2.git

删除后：

[core]

repositoryformatversion = 0

filemode = true

bare = false

logallrefupdates = true

[remote "origin"]

fetch = +refs/heads/*:refs/remotes/origin/*

url = /home/henryyan/submd/ws/../repos/project1.git

[branch "master"]

remote = origin

merge = refs/heads/master

4、提交更改

4.结束语

对于Git Submodule来说在刚刚接触的时候多少会有点凌乱的赶紧，尤其是没有接触过svn:externals。

本文从开始创建项目到使用git submodule的每个步骤以及细节、原理逐一讲解，希望到此读者能驾驭它。

学会了Git submdoule你的项目中再也不会出现大量重复的资源文件、公共类库，更不会出现多个版本，甚至一个客户的多个项目风格存在各种差异。

本文的写作来源于工作中的实践，如果您对于某个做法有更好的办法还请赐教，希望能留下您宝贵的意见。