在实际开发中，经常会遇到下图所示的场景，多个不同的项目工程（工程1，工程2，工程3）中有一个相同的功能模块代码（LibA），这些功能模块可能在以后也会被其他项目工程所引用，按照下图所示，哪个工程需要这个LibA就直接将LibA的源代码引入到当下所需要的项目工程中，这样，我们就可以使用LibA所提供的功能进行开发，如果采用这种方式进行开发，将会面临一个问题，LibA中的功能进行了扩充，那么所有引用libA的工程项目就得重新删除旧的LibA然后再将新的LibA的代码引入到工程中，这种流程操作起来非常的不方便，假如我有100个工程引用了LibA，那我就得为100个工程更新LibA，这种开发效率大家可想而知。
如果我们将上面这个公共库LibA提取出来，让我们所有需要引用libA功能的工程都依赖于同一份的LibA代码，这样的话，如果其中一个工程中更新了LibA的功能，那么其他工程中由于引用的是同一个LibA，它们也将直接获得新增加进libA的功能，而省去的不断发杂的更新其他项目中的LibA中的流程，这种方式不仅有利于libA功能上的扩展，还有利于当LibA中的代码出现BUG的时候，只要进行一次修复，就可以解决其他依赖的项目工程的问题，这种处理的方式可以大大的提高我们实际开发中的效率。
版本管理控制工具Git提供的Submodule（子模块）功能就可以满足我们的这种功能需求，可以解决上诉提出的100个工程就要更新100次LibA代码的问题，大大提高我们在实际开发中效率，接下来我们来看一下，Git是如何使用Submodule来解决我们的问题的。 首先准备好了三个远程的Git仓库（Project1，Project2，CommonLib）分别用于模拟两个开发工程，和一个公共模块，如果不明白如何创建创建远程仓库，可以参看我的另外一篇文章Git仓库创建
再分别为Project1和Project2引入CommonLib作为这两个工程的Submodule（由于接下来的流程Project1和2基本相同，所以只给出Project1的操作流程）
git submodule add 远程仓库地址 添加的目录名
使用Git status命令查看一下当前Project1下，你会看到新增了两个文件，一个是submodule，一个是lib文件夹。
其中，gitmodules文件存放了Project1依赖的submodule的相关信息，而lib文件夹则是用于存放我们引入的CommonLib模块，查看一下gitmodules文件可以发现文件中的信息是指向Project1所依赖的CommonLib的远程Git仓库的地址，如果Project1依赖了多个不同的submodule，则gitmodules文件中存多个不同的path和url一一对应，，其他人clone了Project1工程后也要通过.gitmodules来找到CommonLib，将远程的仓库代码克隆到本地进行使用。
接下来将刚刚Project1添加进去submodule同步到远程仓库中，分别执行以下的操作
git add .git commit -am “相关描述”git push origin master
到此，我们已经为Project1和Project2成功的添加了一个CommonLib作为一个公共的子模块。 此时CommonLib中只有lib.java一个文件，现在要为这个公共模块进行功能扩充，添加一个libex.java，并将新添加的功能更新到远程服务器仓库中。
如果我们需要在Project1和Project2中引用到CommonLib中添加的新功能，那么我们就要去到各个Project中lib目录下，将CommonLib中更新的代码同步回本地，
这样我们就可以使用新的拓展功能进行开发了，使用起来非常的方便，也提高了我们解决问题的效率。
每天告诉自己一次，『我真的很不错』
