Working with Git Submodules
Why Use Submodules?
Modular software
Large projects are often composed of smaller, self-contained, independent software modules. Managing versions of highly modular software raises the following questions:
1. If a bug is detected in one specific version of one module, which versions and products are affected?
2. If a bug is detected in one specific product version, what version of what modules are built into this? And what other products are using the same modules, and should be re-tested now?
3. If we release a new version of a module and we have a wide product portfolio, what products have to be rebuilt?
Modules used in multiple levels at times can be complicated. Things even more difficult when you use modules in multiple levels. For instance, this is an example from one of PTC’s customers:
• There are a huge number of products built from same code base.
• Products may contain multiple components.
• Components may contain multiple modules.
• modules may depend on external libraries.
How to manage modular source code effectively?
Modelling a network of software packages and dependencies is immensely hard with traditional Version Control systems. Most of the time you have to resort to statically copying source code from the module repository to all the dependant ones (push). With the introduction of
Git submodules, these situations can be effectively handled.
Codebeamer provides additional functionality on the top of plain vanilla submodules to support building modular software, like a convenient web interface, a unified look of all
Codebeamer-managed repositories and
Configuration Management Database to support flexible versions of separate modules.