1.甲给一个模块添加submodule
git submodule add <submodule_url> <submodule_dir>
加完子模块还要提交，是比较常规的操作：
git add .
git commit -m “add submodule”
git push origin master
备注：项目根目录下有个.gitmodules文件，里面会记录submodule的信息，比如
[submodule “WEB-INF/src/com/qq/cloud”] path = WEB-INF/src/com/qq/cloud url = http://git.woa.com/Capture/draw-service.git
2.乙第一次拉取有submodule的模块
git clone <project_url>
拉完代码还要初始化submodule：
cd <project_home> git submodule init git submodule update
上面两个命令也可以合成一个：
git submodule update –init
3.甲提交更新到submodule
首先进入submodule目录
直接提交会报错，要理解一个“游离态”的概念。
submodule被引入后，会进入一个“detached HEAD”的状态，也叫游离态。
如果我们进入submodule的目录，执行git branch会提示detached from xxx，当前HEAD不在任何分支。也就是没有任何分支跟踪我们的变更，我们需要回我们的工作分支：
git checkout master
但从经验讲事情往往没这么顺利，因为我们经常会忘了正在用submodule，会改完了去提交的时候才发现，这时候需要做些额外工作，下面介绍3种情况：
1）修改子模块和commit之前，子模块已经处于或者已经从游离态checkout回到工作分支，那么就正常add commit push操作即可； 2）修改了子模块但还没有commit，突然想起来当前处于detached状态，这个时候因为有未提交的修改，checkout会报错，那么你可以git stash先把修改缓存起来，然后checkout回工作分支，再用git stash pop把缓存的修改应用到工作分支上来，或者你想直接丢弃掉修改，那就不pop就好。 3）修改了子模块且commit了，突然想起来当前处于detached状态，这个时候可以checkout回工作分支，但是你commit的修改也就丢失了，这个时候如果需要把这个修改应用到工作分支上，可以把detached HEAD合并到当前工作分支。具体操作：
git checkout master
这时会提示：
Warning: you are leaving 1 commit behind, not connected to any of your branches:
28b0417 test
If you want to keep it by creating a new branch, this may be a good time to do so with:
git branch 28b0417
Switched to branch ‘master’ Your branch is behind ‘origin/master’ by 31 commits, and can be fast-forwarded. (use “git pull” to update your local branch)
可以看到刚才的提交在28b0417上，我们只需合并回master：
git merge 28b0417
然后就是常规操作：
git pull git push
提交完submodule后还要去主模块提交submodule的关联版本，就是常规git add、commit、push，不然别人git submodule update拉取不到新内容，但git submodule update –remote是可以拉到的。
4.乙拉取submodule的更新
首先git pull，但它只会更新主模块。
然后又分两种情况：
1）submodule的提交已经体现在主模块上了，也就是主模块也提交了submodule版本的变更，那就 git submodule update 2）submodule的提交没有体现在主模块上：
git submodule update –remote
这样可以强制拉取子模块的最新版