Git Submodule Use Cases
Use Cases
After a year of hard work, my project had been online for some time, and I thought I could finally catch my breath. Then my manager issued a new command: we needed to develop Project B. Project B had a distinctive feature - it was very similar to Project A in terms of functionality and presentation. The manager wanted it developed quickly, so I needed to consider how to solve the architecture transformation and maximize code reuse.
The overall technical architecture of the project I was involved in was:
Angular(frontend)-----------------node-express(backend)
I consulted many people and thought about it myself. Since our company projects were managed on GitLab, I came up with the following three solutions:
- Everything under one repository, with projects separated only at the folder level, controlled by parameters
- Branch-based approach, like branch-project-a, branch-project-b
- git-submodule
Solution Comparison
Comparing these three solutions:
Solution 1 should definitely be rejected because maintainability would be terrible. It might be convenient for short-term development, but the possibility of human errors and poor maintainability are significant drawbacks.
Solution 2 could work, but it means multiple projects would be developed and managed under one repository. In other words, developers would have easy access to modify multiple projects, which I think is quite dangerous. Additionally, the differential development between Project A and Project B would lead to numerous branches in the future, making maintenance and merging unclear and complicated. After all, they’re not the same project - they’re just similar. So I think Solution 2 should also be eliminated.
Solution 3, the git submodule approach, involves extracting parts of the code into an independent repository, then using git’s submodule mechanism for mapping and inclusion. The submodule itself is also a repository that can be independently developed and maintained. After introducing it into the project, you just use it like a third-party package.
After much consideration, I believe the final solution should reflect two points: Project A and Project B are two separate entities, which means they must exist independently; Project A and Project B have commonalities, which determines there should be some reusability. Based on this, I decided to choose Solution 3.
Experience Using It
Using git submodules is similar to Node.js development, where we use npm to manage all third-party packages - you just use them without trying to modify them directly, because you’re just the consumer.
The introduction and use of git submodules also forces you to extract and abstract the code in your project to a certain degree, making it adaptable to more situations. This significantly helps with code quality, flexibility, and even developers’ own skill development and understanding.
So I recommend that those who encounter similar scenarios in actual development should consider using this mechanism.
