gitsubmodule命令

① Git Submole 使用

git 的 submole 作为一个独立的 repo , 其拥有普通 repo 全部的功能, 我们可以完全按照普通的 repo 管理命令来进入 submole 中进行手动管理. 不过如果存在多个 submole 位于同一 superproject 下时, 掌握一些 git submole ... 命令就变得尤为重要了.

本文列出了常用的一些 git submole 管理命令, 并举出实际应用中遇到的问题及解决方案.

在 git 仓库 superproject 的目录中使用 git submole add https://github/HanleyLee/C 即可将 https://github/HanleyLee/C 作为一个 submole 被 superproject 依赖与管理.

当 submole 被修改时我们可以在 superproject 中得到通知:

在 repo Test 作为 submole 被 superproject 管理后:

添加 git submole 的方法很简单, 使用 git submole add <repo url> 即可. 添加完之后, 在 superproject 的目录下会产生一个 .gitmole 文件, 文件的结构如下:

可以看到, .gitmole 文件中标记了每一个 submole 的 path 与 url .

然后我们进入 ./C :

我们发现 ./C/.git 竟然是一个文件 (常规 git 目录中的 .git 是文件夹), 然后其内容指向了另一个文件夹 (类似于指针), 我们再去到那个文件夹:

我们发现这个文件夹才是 submole 的真实 .git 文件夹, 我们对于 submole 的所做的 commit 信息也都保存在这里.

默认情况下, git pull 命令会递归地抓取子模块的更改 (fetch), 然而, 它不会将 submole merge 到所跟踪的分支上. 因此我们还需要执行 git submole update .

如果我们想一句话解决, 那么可以使用 git pull --recurse-submole , 这个可以在拉取完 submole 后再将其 merge 到所跟踪的分支上.

如果我们想让 Git 总是以 --recurse-submoles 拉取, 可以将配置选项 submole.recurse 设置为 true . 具体命令为 git config --global submole.recurse true . 此选项会让 Git 为所有支持 --recurse-submoles 的命令使用该选项 (除 clone 以外).

如果我们在主项目中提交并推送但并不推送子模块上的改动, 其他尝试检出我们修改的人会遇到麻烦, 因为他们无法得到依赖的子模块改动. 那些改动只存在于我们本地的拷贝中.

为了确保这不会发生, 我们可以让 Git 在推送到主项目前检查所有 submole 是否已推送. git push 命令接受可以设置为 check 或 on-demand 的 --recurse-submoles 参数. 如果任何提交的 submole 改动没有推送那么 check 选项会直接使 push 操作失败.(此外还有 demand , while , no 选项, 参考前节命令列表进行理解)

为了以后方便, 我们可以设置默认检查 git config --global push.recurseSubmoles check

很多人用了 git submole 后, 都发现每次 update 之后, submole 中的 HEAD 都是 detached 状态的, 即使本次 git checkout master 后, 下次更新仍然恢复原样, 难道就没有办法使其固定在某个 branch 上吗? 经过研究, 参考 stackoverflow 的答案, 我发现是可以解决的.

问题的关键在于 .gitmole 的配置:

我们需要添加 update = rebase 这行, 根据 git official 的说明

submole 的 update 有多种选择, 默认情况下是 checkout , 其会根据 superproject 所记录的 submole 的 commit 进行 checkout. 类似于 git checkout 4eda5fgrd , 这必然导致 submole 的 HEAD 处于 detached 状态. 解决办法就是使用 rebase ( merge 也可以), 这样当我们对 submole 设置了一个初始的 branch 后, 其以后都只会在这个 branch 上对远程的最新 commit 进行 rebase , 不会导致 detached 状态的产生.

以 submole 的目录为 ./C/ 为例. 具体的解决步骤如下:

此时, 以后再使用 git submole update 就不会有 detached 状态的产生了

② 关于Ubuntu虚机内git submole的问题

一、Ubuntu系统默认内置：

实际上ubuntu默认没有安装老版本的vi，只装了vim。vi是vim.tiny(vim的最小化版本，不含 GUI，并且仅含有一小部分功能，并且默认与vi兼容。此软件包不依赖于vim-runtime软件包)的一个别名，可用命令ls -l /usr/bin/vi来进行查看vi是指向/etc/alternatives/vi,而/etc/alternatives/vi 又指向/usr/bin/vim.tiny，从命令update-alternatives --display vi可以看出默认情况下，vi当前指向的是vim.tiny。

二、VIM版本及其对比：

不同的编译选项编译出来的vim而已。比如vim是终端下的vim-basic跟vim-tiny，而vim-gnome是用了GNOME2 GUI的vim，在gnome桌面系统上推荐安装vim-gnome。

1、vim-tiny是tiny 版本的vim，就是功能比较少（前面有个+的表示有着功能），但是体积小，速度快。

1、vim-tiny是tiny 版本的vim，就是功能比较少（前面有个+的表示有着功能），但是体积小，速度快。

2、vim-basic：完整版的vim，不过同样没有图形界面，没有菜单

3、更多可以查看帮助文档：http://vimdoc.sourceforge.net/htmldoc/various.html#+feature-list

提示：

ctags的功能很强大，更详细的配置请参考其文档。

建议在~/.vimrc中添加如下配置以使Vim在父目录中寻找tags文件[10]：

set tags=tags;/

设置好后，可在Vim中使用如下功能：Ctrl-]转至最佳匹配的相应Tag，Ctrl-T返回上一个匹配。如果有多个匹配，g Ctrl-]可显示所有备选的tags。如有需要，可互换Ctrl-]和g Ctrl-][11]：

"在普通和可视模式中，将<c-]>与g<c-]>互换 nnoremap <c-]> g<c-]> vnoremap <c-]> g<c-]> nnoremap g<c-]> <c-]> vnoremap g<c-]> <c-]>

使用:make可调用make命令编译程序，配合Vim内置的QuickFix功能，可以像IDE一样打开一个窗口展示编译错误和警告，通过它还可以方便地跳转到各编译错误的产生位置。

常用的命令有:cw[indow]（如有错误打开quickfix窗口）、:cn（跳到下一个错误）、:cp（跳到前一个错误）等，具体可:help quickfix。

如果想在有错时自动打开quickfix窗口[12]：

" 编译后，如有错误则打开quickfix窗口。（光标仍停留在源码窗口） " " 注意：需要开启netsting autocmd autocmd QuickFixCmdPost [^l]* nested cwindow autocmd QuickFixCmdPost l* nested lwindow

默认情况下，:mak[e]会跳转到第一个错误，如果不想启用这个功能，请使用:make!。

代码较长时可启用代码折叠功能，如按语法高亮元素折叠：

set foldmethod=syntax "默认情况下不折叠 set foldlevel=99

随后即可使用z系列命令管理代码折叠。如za会翻转当前位置的折叠状态，zA会递归翻转当前层所有代码的折叠状态等。当然也可以把功能键映射到za:

map <F3> za

K键可用于查看当前函数的文档。

近来仍被积极维护的代码托管在 GitHub 上的插件[13]：