随着git的使用,我们开始习惯性的用git进行项目的管理,但是作为天选牛马,我们往往需要参与不同的项目,这些项目中的某些功能是相同的。这时出于解耦和模块代码独立运维管理的需求,我们一般会针对一些功能实现进行独立的子仓库管理,当然除了自己的,我们可能也会用到一些第三方的仓库。 他们的一个共同特点是有一个独立的仓库进行管理,同时作为一个相对独立的功能实现在我们的仓库中被使用。
丑陋一点的方法把所需模块的源代码都拷贝到主项目里,这样主项目就变成一个完整的项目了。但是显而易见的,如果子仓库有一些独立的优化或性能升级,那么在我们主项目进行同步,或者我们的一些开发需要同步到子项目这些工作都会非常麻烦,甚至随着项目增加而成为灾难。
显然,我们需要一个更好的解决方案。而git submodule 模块就是为了解决这个问题而生的,submodule 让我们可以将一个 Git 仓库作为另一个 Git 仓库的子目录。 它能让你将另一个仓库克隆到自己的项目中,同时还保持提交的独立。
配置
首先介绍一些配置可以在后续使用中减少键盘的敲击~~, 因为后续可能是复用比较多的配置代码,所以卸载最前面
1 | 使用git status 直接显示你的子模块的更改摘要 |
使用
添加子模块
我们首先将一个已存在的 Git 仓库添加为正在工作的仓库的子模块。 你可以通过在 git submodule add 命令后面加上想要跟踪的项目的相对或绝对 URL 来添加新的子模块。 在本例中,我们将会添加一个名为 “DbConnector” 的库。
1 | git submodule add https://github.com/chaconinc/DbConnector |
添加子模块并指定目录
默认情况下,子模块会将子项目放到一个与仓库同名的目录中,本例中是 “DbConnector”。 如果你想要放到其他地方,那么可以在命令结尾添加一个不同的路径(eg:scripts/DbConnector)。
1 | git submodule add https://github.com/chaconinc/DbConnector scripts/DbConnector |
如果这时运行 git status,你会注意到几件事。
1 | git status |
.gitmodules
我们通过 git submodule add 拉取子仓库后,会增加了一个 .gitmodules 文件。 该配置文件保存了项目 URL 与已经拉取的本地目录之间的映射:
1 | [submodule "DbConnector"] |
如果有多个子模块,该文件中就会有多条记录。 要重点注意的是,该文件也像 .gitignore 文件一样受到版本控制。 它会和该项目的其他部分一同被拉取推送。 这就是克隆该项目的人知道去哪获得子模块的原因。
变更子仓库的配置
- 修改
.gitmodules文件中对应模块的url属性; - 使用
git submodule sync命令,将新的URL更新到文件.git/config;
再使用命令初始化子模块:git submodule init
最后使用命令更新子模块:git submodule update
子仓库信息
在 git status 输出中列出的另一个是项目文件夹记录。 如果你运行 git diff,会看到类似下面的信息:
1 | $ git diff --cached DbConnector |
虽然 DbConnector 是工作目录中的一个子目录,但 Git 还是会将它视作一个子模块。当你不在那个目录中时,Git 并不会跟踪它的内容, 而是将它看作子模块仓库中的某个具体的提交。
如果你想看到更漂亮的差异输出,可以给 git diff 传递 --submodule 选项,可以在diff的时候,展示更详细的模块信息(远程仓库和版本变动)。
1 | git diff --cached --submodule |
提交
整体而言,提交带子仓库的模块和普通的提交推送所需要的操作是一样的.
1 | 提交时,会看到类似下面的信息: |
只不过注意看的化会发现 DbConnector 记录的文件类型是 160000 模式。 这是 Git 中的一种特殊模式,它本质上意味着你是将一次提交记作一项目录记录的,而非将它记录成一个子目录或者一个文件。
子项目获取
直接初始化并拉取子项目
这是一个更为简单的方式, 在执行 git clone 命令时,传递 –recurse-submodules 选项,它就会自动初始化并更新仓库中的每一个子模块, 包括可能存在的嵌套子模块。
1 | git clone --recurse-submodules https://github.com/chaconinc/MainProject |
单独拉取子项目
如果准备单独拉取子项目内容,那么我们开始的初始项目克隆和正常项目是一致的,只不过我们拉取下来的项目中,子项目只会是一个空目录,里面没有完整的子项目内容。
我们需要运行两个命令:git submodule init 用来初始化本地配置文件,git submodule update 则从该项目中抓取所有数据并检出父项目中列出的合适的提交。
或者我们也可以使用 git submodule update --init 命令一次性完成初始化并更新操作。
如果还要初始化、抓取并检出任何嵌套的子模块, 请使用简明的 git submodule update --init --recursive。
1 | git submodule init |
现在 DbConnector 子目录是处在和之前提交时相同的状态了。
子项目同步
我们有一份包含子模块的项目时,我们将会同时在主项目和子模块项目上与队员协作。
从远程仓库中同步子项目
项目中使用子模块的最简模型,就是只使用子项目并不时地获取更新,而并不在你的检出中进行任何更改。 我们来看一个简单的例子。
直接操作子仓库
如果想要在子模块中查看新工作,可以进入到目录中运行 git fetch 与 git merge,合并上游分支来更新本地代码。这和我们在主项目中运行 fetch 与 merge 的方式完全相同。
通过submodule管理
你不想在子目录中手动抓取与合并,那么还有种更容易的方式。 运行 git submodule update --remote,Git 将会进入子模块然后抓取并更新。默认会更新所有的子模块。
1 | 更新指定子模块,默认使用 master 分枝 |
子仓库冲突处理
你和其他人同时改动了一个子模块引用,那么可能会遇到一些问题。 也就是说,如果子模块的历史已经分叉并且在父项目中分别提交到了分叉的分支上,那么你需要做一些工作来修复它。
1 | git pull |
Git 在这里指出了子模块历史中的两个分支记录点,并且不能自动进行合并。这是你可以通过 git diff 查看具体的差异
1 | git diff |
eb41d76 是我们的子模块中大家共有的提交,而 c771610 是上游子仓库进行的提交。这时候我们需要单独进行子仓库的冲突处理(处理方式和正常仓库的处理一样,只是我们需要进入到子仓库进行操作。
1 | 进入子仓库的目录,后续相关操作都是针对子仓库的 |
当然可能在merge的时候,会存在一些文件冲突,这时候,就是正常的处理冲突文件,提交推送即可。
1 | vim $conflict_File |
父项目同步
拉取
1 | 默认拉取父项目 |
默认情况下,git pull 命令会递归地抓取子模块的更改,如上面第一个命令的输出所示。 然而,它不会 更新 子模块。这点可通过 git status 命令看到,它会显示子模块“已修改”,且“有新的提交”。 此外,左边的尖括号(<)指出了新的提交,表示这些提交已在 MainProject 中记录,但尚未在本地的 DbConnector 中检出。 为了完成更新,你需要运行 git submodule update:
1 | git submodule update --init --recursive |
推送
如果我们的子模块目录中有一些改动。如果我们针对父项目进行提交并推送但并不推送子模块上的改动,其他人因为他们无法得到依赖的子模块改动,他们在执行项目的时候会遇到麻烦,
为了避免这个问题,可以让 Git 在推送到主项目前检查所有子模块是否已推送。 git push 命令接受可以设置为 check(检查是否推送) 或 on-demand(自动推送未推送的子模块) 的 --recurse-submodules 参数。 如果任何提交的子模块改动没有推送那么 check 选项会直接使 push 操作失败。on-demand会尝试推送子模块
1 | 推送主项目更改时,会自动检查所有子仓库的更改是否已经推送 |
子模块的技巧性操作
遍历
有一个 foreach 子模块命令,它能在每一个子模块中运行任意命令。 如果项目中包含了大量子模块,这会非常有用。git submodule foreach "$git_command" 可以让我们对任何一个子模块执行某个相同的命令。
1 | 将所有子模块的更改进行暂存 |
别名
可以看到很多命令的参数非常长,尤其是在使用子模块后,额外增加了一些参数,但是 git 并不支持将这些选项作为它们的默认选项。
我们可以通过为这些命令设置别名来简化我们的操作命令,这里有一些例子。
1 | $ git config alias.sdiff '!'"git diff && git submodule foreach 'git diff'" |
从子目录切换到子模块
有时候我们想把项目中的一部分工作或者功能,独立抽象出来,形成一个单独的模块(改成子仓库单独保存),那么我们需要先取消暂存对应子模块代码所在的目录(否则会由于目录以存在产生冲突)。 然后才可以添加子模块
1 | git rm -r subFunction |
现在假设你在一个分支下做了这样的工作。 当你切换到其他分支(文件还在子目录而非子模块中)时——你会得到这个错误,所以在切换时,需要进行强制(-f)切换分支 :
1 | 正常切换由于模块目录在目标分支是父项目的一个目录存在冲突会报错 |
子模块的注意事项
切换分支
在切换分支使用 git checkout 命令时,最好添加 --recurse-submodules(git ≥2.14),来确保父项目分支切换后,子项目会和分支实际情况保持一致。
通过 git config submodule.recurse true 设置 submodule.recurse 选项, 告诉 Git(>=2.14)总是使用 --recurse-submodules。 如上所述,这也会让 Git 为每个拥有 --recurse-submodules 选项的命令(除了 git clone) 总是递归地在子模块中执行。
如果使用了子模块,直接进行相关的设置吧,旧版本的一些潜在风险笔记多,但是我们似乎在这也不需要再去过度纠结旧版本的问题了,毕竟此刻,刚开始的你和我可以直接使用新版本。
参考
起始就是边看边抄了一遍 git doc:git-submodule