When we store all(or most) of our source code in a single git repository, we term the git repository as mono-repository. Mono-repository usually contains multiple applications, and several reusable libraries.
Typically, when a developer needs to debug a library source code, they have to first clone the library source code and then somehow link the library and application source code together.
Also, if a developer has to update a library, they have to again clone the library source code, make updates and then verify the resulting package. Upon verification, dev publishes newer version of the library.
Assuming, a developer is paid $100 per hour. If the developer has to follow this pattern of updating libraries, it will usually take them at-least an hour resulting in $100 loss to business.
Compare this approach to a monorepo, where actual application and library code are in the same git repository and developer doesn't have to do much to update/debug the library source code saving company's overall time
In the case of multiple repositories, when some developer updates the library, they will usually update the library only in their application. This means that other applications using the same library will be out of date soon. Also, it will be harder for a developer to make a breaking change since all of the consuming applications will be impacted.
Interestingly in the case of monorepo, developer can scan for usages of the library code in all applications and modify it within few minutes. Furthermore, all the applications will always be using latest version of library.
When a new developer joins your team, he/she will have to clone multiple git repos and understand the hierarchy whereas in monorepo approach, he/she will just have to git clone one repo.
We get to hear this argument from others having opposite opinion that in a monorepo, build times are higher since all libraries will need to be built all the time. However, with latest tools and advancements, build tools can cache previous builds and only build projects that actually need to be built using some heuristics.
When we create a release, we can tag the repo at that time, which means even after a year, if we git clone with the same tag name, we can recreate the same release packages.
This would be difficult with multiple repositories since each repository would need to be tagged and who knows one might forget to tag one or the other repo.