Usually when we think about Git repos we are assuming the multirepo type where each project or microservice has its own repository. The other two types of repos being monorepo and Git submodules have their own purpose as well that will be the topic of discussion for today.
Prerequisites
- Git
Solution
multirepo
The standard solution where anything from a simple app to a distinguish piece of software (microservice) is hosted in separate repositories. Chiefly, one repo per project.
Pros:
- Simple implementation.
- Independent and fast release cycles …the usual DevOps stuff.
- Independent versioning.
- Granular access control by typically assigning one or multiple teams per repo also called code autonomy
Cons:
- Resyncing shared libraries.
monorepo
Monorepo could be defined as a single repository where all projects and libraries are hosted. Basically, the whole codebase put into a single place. All things in one bag. The big tech companies such as FAANG are known for utilizing the monorepo approach.
It’s worth to note that monolith not equal to a monorepo. A monolith software is a single-tier application where all components are combined into a single product. By default, a monolith app code is not necessarily stored in a monorepo, although it’s plausible. Monolith vs microservice is discussion for another time though.
Pros:
- Single source of truth.
- Removes duplicated dependencies.
- Sharing the same development and PR strategy.
- Robust against breaking functionality.
Cons:
- Long compiling time.
- Rethinking the CI/CD strategy.
- Include special tools.
- Scalability.
- Maintaining clean Git history.
Git submodules
Submodules is a Git feature that allows you to include another Git repo as a reference to a certain commit this submodule is pointing at. In a way it’s kind of an embedded repo, think of it as a Git symbolic link to another repo. Generally, the submodule metadata is saved under a .gitsubmodules file.
You might want to consider using submodules when there is an external dependency as a library or component which is not frequently updated, and it’s shared between multiple projects.
Pros:
- Native Git solution.
- Single source of truth.
Cons:
- Unexpected behavior if not used with the correct workflow.
- Complicated if you deal with nested submodules.
Conclusion
As a rule of thumb, make use of a single repo per project whenever possible.
To find more neat Git commands and hacks, simply browse the Git category. Feel free to leave a comment below and if you find this tutorial useful, follow our official channel on Telegram.