Mono- or Multi-repo?

The last year or so has seen a significant increase in people discussing, and using the monorepo pattern for source control of projects. I suspect this is directly related to the number of ‘big tech’ companies, such as Facebook and Twitter who actively use, tweet and blog about their successes with the pattern. As everyone knows, anything the big players are using naturally gains momentum across the broader development community. I’ve worked with both mono- and multi-repo projects, so I though it would be interesting to see the pros and cons of each, and to discuss my experiences with both.

TL;DR; both patterns have pros and cons, and neither is a silver bullet. You should understand these benefits and limitations, and use them to come to an informed decision on what’s best for you and your project.

The Monorepo Pattern

At it’s core the monorepo pattern is extremely simple; create a single source control repository, and put all of the code for the project in that single repo. During the years where we were building (manually generally) and deploying (again, generally manually) monolithic applications I’d say this was the de facto way of working. So much so that it didn’t really have a name, it was just “using version control”. It made sense to work this way, the VCS pattern matching that of the deployed software. Everything was relatively easy to find, as it was all in one place, and one clone of the repo gave you everything you needed to get working on the project. It also promoted code sharing within the project, as there was great access and visibility of all of the code, regardless of who or which team had built it.

The Multirepo Pattern

As we moved from large monoliths into what we’d consider ‘more modern’ architectures for our software, generally featuring collections of smaller and more independent modules, the monorepo became a less obvious VCS pattern. Certainly it was still used, but creating a collection of modules also suggested the “repo per module”, or multirepo pattern might be a good option. This pattern allowed each repo to be treated separately, so if you had a mix of languages and teams, this was great. As CI and then CD became more pervasive there were also significant advantages, as you could have different process per repo.