Mono-Repo vs Multi-Repo: Throwing Light On Code Repository Strategies

Mono-repo and Multi-repo are two main strategies for hosting and managing code through Git. We discuss both the strategies and their pros and cons in detail.

Introduction

Most of the modern projects are managed and hosted on Git. Git has become the standard platform for distributed source code management, version control, and collaboration from anywhere in the world. Git is fast and efficient. There are two main approaches to host and manage your Git code:

• Mono-repo
• Multi-repo

Before digging into these approaches, let’s understand how repo works.

What are Repos?

A Repository (Repo) contains all the folders and files of your project. It also contains information about users, people, and computers.

The repository data is version-controlled. A repo can be owned by an individual or a group of team members.

Git is a repository. It can be public, private, or internal. GitHub is a hosting service of Git repository and has a user interface.

Git provides version control and code sharing features, however, what makes Git different is that if developers want to do some changes to their files, they can copy the entire repository to their local system. Thus, even if a developer doesn’t have write access to a particular project, they can copy the contents locally and modify them (called forking).

Further, if the developer wants to share locally made changes, they can send a “pull request” to the owner of the project.

A project can have a single service. If your project has multiple workflows, you may create multiple services for each workflow. Most developers prefer splitting larger projects into smaller independent services, having one or more functions. Each service can solve various business problems. With the popularity of serverless frameworks, users can access functions as services.

Once you create these functions-as-services and deploy them, the next step is to structure and version control them – you can have all your services in one repository (mono-repo) – or have a separate repository for each service you have (multi-repo)!

What is a Mono-repo?

In a mono-repo approach, you can keep all your services in a single (mono) repository. You can still deploy and manage each service independently. The services can share common libraries and code.

Companies like Facebook, Google, and Dropbox use mono-repo.

Advantages of Mono-repo

Mono-repo approach has many advantages:

• A single place to store all the project code, and can be accessed by everyone in the team
• Easy to reuse and share code, collaborate with the team
• Easy to understand the impact of your change on the entire project
• Best option for code-refactoring and large changes to code
• Team members can get an overall view of the entire project
• Easy to manage dependencies

Disadvantages of Mono-repo

Of course, mono-repo has some disadvantages, the main one being the performance. If your project grows and more files are added every other day, the check-out, pull and other operations might become slow and file searches may take longer.

Also, if you hire a lot of independent contractors for your project, giving them access to the entire code base may not be so secure.

Further, it is difficult to implement Continuous Deployments (CD), because many people can check-in their changes, and your Continuous Integration (CI) system may have to do multiple rebuilds.

Large companies that use mono-repos have customized tools to handle the scaling-up issues. For example, Facebook uses a custom file system and source control.

What is a Multi-repo?

In a multi-repo approach, there are multiple repositories that host several libraries and services of a project. If a service changes, developers need to rebuild only that service and not the entire project. Individuals and teams can work on their specific services and they get access to only the required services.

Companies like Netflix and Amazon use multi-repos.

Advantages of Multi-repo

The number of companies adopting multi-repo is way more than those going for mono-repo, because of the following reasons:

• Each service and library have its own versioning
• Code check-outs and pulls are small and separate, thus there are no performance issues even if the project size grows
• Teams can work independently and need not have access to the entire codebase
• Faster development and flexibility
• Each service can be released separately and have its own deployment cycle, thus making CI and CD easier to implement
• Better access control – all teams need not have full access to all the libraries – but can get read access if they need

Disadvantages of Multi-repo

• The dependencies and libraries used across services and projects have to be regularly synced to get the latest version
• Encourages a siloed culture at some point, leading to duplicate code and individual teams trying to resolve the same problem
• Each team may follow a different set of best practices for their code causing difficulties in following common best practices

Differences between Mono and Multi Repo

Let us recapitulate the differences between mono-repo and multi-repo:

Conclusion

Both mono-repo and multi-repo are equally popular and which one is better depends on your project size, project requirements, and the level of versioning and access control you need.

Mono-repo favors consistency, whereas multi-repo focuses on decoupling. While in a mono-repo, the entire team can see changes done by one person, multi-repo creates a separate repo for each team, who have access to only the required services. If you want to use a combination of mono-repo and multi-repo for your projects, you can go for meta, a tool to manage multiple projects and libraries.

You may also be interested in Free Resources to Learn Git.