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分支上，那么下一个进行子模块开发的人，就会包含到最新的代码

转载于:https://juejin.im/post/5cae05e25188251b19486e8d