Software projects that use SVN as a version control system and have a modular structure benefit from managing individual modules together under a parent repository. In SVN, it is therefore common to use a project structure that enables a clear separation of the modules.
This structure offers particular advantages when components are published separately. For example, a bugfix can be rolled out in "Module A" without having to republish (release) the entire project. The CI/CD pipelines of such projects are specially designed for this structure. A planned migration from SVN to Git then presents the project team with a challenge. They have to map the structure in Git without incurring high costs for the conversion of the project and the CI/CD pipelines.
A simple solution is to maintain the modules as separate repositories. However, this is not very scalable. If a project comprises several hundred modules, joint administration must be possible.
Git offers two tools that can solve this problem: Git Submodules and Git Subtree. Both provide the necessary functions to maintain the modular structure and enable shared management.
Both Git Submodules and Git Subtree represent each module as an independent repository. The independent repositories allow developers to take advantage of module-based publishing.
Differences between submodules and subtree
At first glance, the tools appear to be very similar, but there are fundamental differences, especially in terms of handling. Git Subtree is characterized by the fact that the parent repository contains the entire code of the modules. This means that the repository works like a normal Git repository in everyday use. In contrast, Git Submodules only stores a reference to the repositories of the individual modules, which developers must take into account in their daily work. The remote parent repository does not contain any physical copies of the modules. The modules are only created as physical folders for local development when they are checked out from the parent repository.
The necessary commands can be found in the Git documentation. The biggest difference in operation is that with Git Subtree, the changes are committed to the parent repository and the individual modules are synchronized as required. Whereas with Git Submodules, the changes are checked into the module repositories and only the commit reference is updated in the parent repository. This means that with Git Subtree you can create branches from the parent repository in your repository, which then contain all modules. This is not possible with Git Submodules, where you have to create separate branches for each module. Depending on the project environment and the chosen working method, it may be more advantageous to branch the entire repository or only create individual branches.1
In terms of the user-friendliness of the two implementations, Git Subtree has the advantage that fewer commands are required in day-to-day work, as developers can execute commands such as commit and push in the parent repository. On the other hand, problems with Git Submodules are limited to individual modules and may therefore be easier to handle.
Decision
The decision between these two approaches must be carefully weighed up depending on the project - a general recommendation cannot be made. With both Git Subtree and Git Submodules, modular repositories can be managed in a Git repository while separate publication is possible. However, it should be noted that both implementations entail a certain overhead and make administration more difficult compared to a standard Git repo.
