Git: 如何在你的项目中正确使用Submodules
在学习使用Backbone.js时，会用到许多第三方插件，这些插件也都是Github上的一个一个的小项目，想要既要保持自己的Git仓库记录，同时也能跟进第三方插件项目的状态，就可以使用Git里的Submodule，通过在当前项目中添加Submodule，可以将自己的项目仓库与插件仓库进行很好的隔离，并允许你对它们分别更新，而不会互相影响。
为当前项目添加Submodule
git submodule add (repository) (directory)
git submodule add https://github.com/jashkenas/underscore.git lib/underscore上面使用git submodule add将underscore.js克隆到了Backbone项目的lib目录下，此时可以通过git submodule status可以看到刚才添加的submodule的log信息，再使用git status查看一下当前仓库状态，就会发现新多出来两个文件.gitmodules和lib目录，前者用于记录submodule的元信息，后者是submodule的实际存放路径。
此时，我们还需要做一步，就是将刚才对仓库的变动做成一个commit，并提交到远程的repo中，这样才算完整。具体做法与平时无异，git commit -m”blabla..” && git push。 到这里，你的远程仓库中也能看到这次变动了。
克隆含Submodule项目的正确姿势
刚才添加的submodule已经在你的远程repo中了，此时，一个新加入团队的一个小伙伴需要clone你的项目加入开发，这时他的操作需要特别注意，单纯的git clone命令并不能完整的clone到项目的全部，正确的做法是：
git clone (repository) (directory)git submodule initgit submodule update
上面三步，分别克隆仓库代码到本地、初始化注册submodule到指定路径、更新submodule到本地，相信聪明的你一定已经猜到了，这里的关键其实都在.gitmodules目录中，这里记录了submodule的元信息，这个有点类似npm中的package.json文件，管理版本的时候不需要传送真实文件，记录了源地址后，更新时，直接重新下载一份相同版本的即可。
不过除了上面的分步执行外，git clone 还有两个叫--recursive与--recurse-submodules的命令行参数，使用这两个参数可以在clone仓库的时候一并把submodule也拉到本地。
git clone --recursive (repository)
git clone --recurse-submodules (repository)更新项目中的Submodule
因为Submodule与仓库的Git信息是隔离的，所以你可以像操作两个不同仓库代码一样，分别对这两个仓库使用Git命令，更新Submodule其实就是在Submodule目录中使用git pull命令拉取最新变动。其它Git操作类似，就把它当成独立的仓库就好。
删除不用的Submodule
最后的场景，当你不在需要一个Submodule时，该怎么办，直接删除掉文件吗？显然不是，因为在初始化注册Submodule的时候，一些Submodule元信息被写到了好几处，如果直接删除就会导致一些数据不一致的问题。正确的做法应该是在删除本地Submodule文件的时候，一并把那些元信息也铲除掉。
这些Submodule的元信息分别存储在.gitmodules与.git/config中，打开这俩文件，把涉及待删除的Submodule信息分别移除。
做完了上面的操作，再执行以下git rm --cached <path/to/submodule>就算完全删除了。
嗯，常用场景也就这几个了，最后啰嗦一下，其实git submodule就是一个让多个不同Git仓库在一个项目中共存的方案，Get√了这个技能，回头可以把Vim中的Pathogen里的插件都用这个管理上。
-完-