We often reference other libraries and components, sometimes from ourselves, sometimes from other projects, and sometimes from third parties. If you need resources, you can use AAR and put them on maven server, or even put them on JCenter and directly rely on them remotely. But there are also some problems, aar is not flexible enough. Each modification needs to be packaged and uploaded to AAR, and it involves snapshot and official package management, which is quite troublesome. Although the local Module is flexible enough, it cannot be easily used by others. Is there a compromise idea? Consider git subModule in this case
As long as the project uses Git management, you can integrate the Git submodule, which is equivalent to another set of independent Git project integration, and you can even set up another git submodeule
Create an empty project first: To facilitate the management of subModules, it is recommended to create an empty folder, called SubModules in this example
Then create a subproject and upload it to a remote Git server
Go back to the root of the main project, download and bind the subprojects
Git submodule add github.com/ * * * * * * / Base… submodules
Git submodule add — git submodule add — git submodule add — Git submodule add — Git submodule add — Git submodule add — Git submodule add
Once the download is complete, you can see a new project
Foreach update, just execute git submodule foreach git pull and update all the submodule code
As mentioned above, git submodule is a separate Git project, so branch management of code does not switch with branch switch of main project. Branch switch of sub-project requires CD to corresponding directory and manual switch (as shown below). In actual development, it is not recommended to create branch for sub-project, but a master branch is ok. Otherwise there would be management chaos
As for modification and update, the subproject is also a separate project, so it can be opened directly during modification, pushed directly to the remote side after modification, and then pulled down after switch to the main project. It should be noted that the corresponding subModule hash will also change next time the main project pushes the code. A separate Git commit record is also generated for updating subModule code
When subModule updates frequently, there are a lot of additional commit records (a disadvantage)
Also note if some packaging platforms support this and if they use your submitted submodules every time they pull git subModule code, or if they pull the latest submodule code, ignoring your submission record. I have personally encountered cases where the infrastructure group used the latter approach to packaging, resulting in incorrect code
Finally, a brief description of subModule usage. Although the code has been downloaded and bound to the local project, it cannot be called by default and requires a few simple configurations
Look at.gitModules. This is generated by default when you add subModules, and it sets the address of the project
First we need to modify the setting, notice that the projectDir address should be the folder we just created
Then add an application to build.gradle to use the code resources in the SubModule
The same is true for referring to multiple projects
In general, Git subModule is a lighter solution than AAR, which saves the trouble of uploading and version number management. In addition to paying attention to the packaging platform, the overall experience is good, especially when a module is frequently updated and iterated, and there are multiple external projects dependent on it, it can be a reasonable solution to try