背景
有些公司的项目可能需要做到两个或多个项目公用一个业务组件，比如项目A和项目B公用一个业务组件A，如果项目使用的是Git来管理的话，业务组件A的源码是放在项目A中的，通常我们都是把业务组件A打包成jar或者aar，然后把包上传到公司内部的maven仓库中，项目B通过引用该包的maven 坐标（groupId, artifactId, packaging, version）来进行依赖。但是这样做项目B的同事可能会拿不到业务组件A源码来修改，因为项目A和项目B可能在不同权限组。
你可能会说maven不是可以上传源码的吗？项目B的同事可以读取到源码。的确是可以maven上相关包的源码，但是这不能修改。
你可能会说干嘛要修改，业务组件A是属于项目A的同事才有权去修改的，项目B的同事只要拿来用就行，不需要管怎样去修改。的确是这样的，项目B的同事只需要拿来用就行，这也是比较合理的。
但是实际情况，项目B可能在使用业务组件A的时候可能遇到一些比较难以复现的问题，这种情况下实在没有办法只能引用业务组件A源码进行调试。所以像这种业务组件A其实最好还是单独作为一个项目来管理好一些。
怎么把业务组件创建成一个项目来单独管理
首先我们来创建一个项目SubmoduleStudy，然后对这个项目配置Git管理，为它生成一个名字叫common的Android Library Module，这时候项目的结构是下面这样的，大家应该都很熟悉。
一个可运行的app和一个普通的common基本就是这样结构，我们上面说了需要把业务模块进行分离，成为一个项目，然后还可以对这个项目的一个模块进行引用。
接下来我们单独为common创建一个项目，跟SubmoduleStudy一样的创建，名字叫SubmoduleStudy_common项目，然后包含一个之前一样的common module。如下图所示。
SubmoduleStudy里面的common module可以删除了。
还是一样的你得把SubmoduleStudy_common用Git管理起来，然后在主工程SubmoduleStudy的根目录下运行
git submodule add <repository> <path>,记得后面接的是SubmoduleStudy_common的仓库地址。
完成你就可以看到如下图的目录结构，这样就可以把业务模块项目引进来了。
而且你还会发现多了一个文件.gitmodules。里面就是关联了SubmoduleStudy_common。
这个时候打开IDE右边的Gradle栏就会发现其实整个项目并不能找到SubmoduleStudy_common。
接下来就是重要的一步了，我们得找到项目根目录的settings.gradle打开进行对SubmoduleStudy_common下的common进行关联。
好了，这个时候项目才能识别到这个业务组件。
接下来主项目就可以对这个业务组件进行依赖了。
我们暂时先不管SubmoduleStudy_common下的app，我们对SubmoduleStudy 的 app的dependencies配置上implementation project(":common")这样就可以实现依赖了。
在前面的步骤中，当我把SubmoduleStudy_common关联到主项目的时候，通过观察IDE右下角的分支那里还可以看到 SubmoduleStudy_common也是可以切换分支的，是不是挺方便的。
在SubmoduleStudy_common中有个app，这个app有啥用呢？因为我们把SubmoduleStudy_common拆分成一个独立的模块，这个app自然用来调试common，也可以用来写一些测试common的方法。我一般把他的名字改成xxx-sample。
需要注意的地方
开始我已经说过，这种做法并不一定适合任何项目，正确的做法还是通过maven去管理该模块。
你可以发现SubmoduleStudy_common这个项目下builde.gradle在SubmoduleStudy项目里面是没有任何作用的，目前我还不知道是否可以配置两个根builde.gradle，我的直觉告诉我应该是不行的。
所以这就导致SubmoduleStudy_common这个项目的一些builde.gradle上的配置需要放到SubmoduleStudy项目上，包括仓库配置，gradle版本等等。
