Git submodule使用指南（二）

以前发布了git submodule使用指南（一），今天这个第二篇，会写一些修改方面的操做和个人理解。

我我的认为，子模块在使用的过程才是最值得注意的地方，因此也没有跟上面的内容一块儿做为“增删改查”系列写下去。 “改” 我认为是最重要的一环。其中又能够分为：

1. 对本地的子模块进行修改
2. 更新他人修改的子模块内容

对本地的子模块进行修改

上面提到更新子模块的操做

git submodule update --remote
复制代码

可是此时的子模块是出于一个特殊的状态，虽然上游的变化被更新到了本地，可是本地子模块会处于一个游离的HEAD状态。

在HEAD状态下，若是将本地修改的内容进行commit，是不会“附着”到任何分支上的。游离的内容，会在切换分支以后消失。

那怎么操做才是正确的呢？

1. 先进入子模块，而后检出一个分支。
2. 再执行commit等本地操做
3. 执行git submodule update —remote —merge，将上游的变化合并到本地的这个分支上。若是你忘记—rebase或—merge，Git 会将子模块更新为服务器上的状态。而且会将项目重置为一个游离的 HEAD 状态。要弥补这个错误的话，从新执行1和3就能够了。
4. 若是本地的文件跟上游文件出现冲突，则按照普通解决办法解决了再提交就行了。
5. 发布改动（推送）：在父仓库执行git push时添加--recure-submodule 参数，此参数表示递归子模块，能够设置为2个值“check”和“on-demand”。check会使没推送子模块的父仓库自己推送失败。而on-demand会尝试自动推送子模块后再推送父仓库，若是子模块因为其余缘由失败，那么父仓库也会推送失败。

合并子模块的改动

根据Gitbook的描述，这是当同一分支在本地和上游出现了不一样分叉，须要进行合并的时候，而且两者不是祖先和后代的关系（或者说不是一条分子上的提交）。

操做方法以下：

1. 对上游的提交，进行检出分支
2. 将1检出的分支，合并到本地
3. 解决冲突
4. 回到主项目
5. 检查子模块的记录
6. 解决子模块冲突
7. 提交主仓库合并

一些我我的的理解

子模块的使用上面说得可能仍是有点比较绕，我我的认为比较合适咱们团队的子模块工做流应该比较简单。

1. 主项目须要在自模块上开发新功能时，须要在主项目内的子模块开新分支，而后进行开发
2. 子模块的代码须要独立提交，造成commit信息记录在主仓库
3. 因为主项目最终也是须要进行打包的，因此子模块的版本只要是基于master，就认为是可信的
4. 最后主项目的整个版本通过验证须要上线后，则将子模块的分支合并到子模块的master分支上，那么下一个进行子模块开发的人，就会包含到最新的代码