This article was written by a guest author.

For businesses and organizations that offer any sort of digital experience, code quality and security is of cardinal importance. As such, the architecture of that code – how it is stored, accessed, and built upon – is critically important.

In this age of digital transformation, if you’re standing still, you’re moving backward. One moment you’re considering how to evolve your architecture to offer an omnichannel experience; the next, you’re reading an HDFS Hadoop introduction by DataBricks while assessing the impact of Big Data on your business. The pace of technological change is quite dizzying.

To keep pace, businesses need to keep evolving their code. Hence the role of Git as the most widely used source code control management system in the world. In software, there are always bugs to be fixed, functionality to improve, new features to add, or new features to release. The architectural decisions about code storage have implications for all those actions, which brings us to the Git multi repo vs Git mono repo question. 

Git Multi Repo vs Git Mono Repo

The great debate that has bubbled in recent years concerning the relative merits of the Git multi or mono repo approaches reflects this. 

It may be tempting to look around and see what the tech giants are up to. Look at Facebook, Google, Netflix, and Uber. They all use vast mono repositories. So that must be the best approach, right? Well, not necessarily. It depends on the business.  

This article won’t give a single, one-size-fits-all answer. There simply isn’t one. It’s contingent on factors such as your business’s size, resources, and requirements. The best approach for your business may well change over time. And, for many businesses, some sort of combination or hybrid version may be appropriate.

Differences Between a Git Mono Repo and Multi Repo Approach

What is meant by mono-repository and multi-repository storage? This refers to how an organization stores its code in Git, whether in one large Git repository, or in multiple, smaller repos.

Git Mono Repo

A mono-repository approach is where a single location, or repository, contains multiple projects from across the business. Google, as show in in the example from 2015, had a single, vast Git repository housing code for all its services.

Large mono repositories can be organized into directories to provide some sort of internal structure.

Git Multi Repo

A multi-repository approach is where the organization’s code is distributed across multiple Git repositories. The number of repositories will vary, but it will be based on a logical splitting of the code. For example, it may be that each project will have its own location.

The architectural decisions here can reflect and inform the business’s entire culture. Does the development team move quickly? Do teams work  collaboratively across departments? Are there clear lines of ownership? These points are all relevant to the debate.

Here are some advantages and disadvantages of these approaches.

Git Mono Repo: Pros & Cons

This is where the code from multiple projects is stored in a single location, with all developers at the organization working with that same repository.

Advantages

For some businesses, the Git mono repository approach might offer these advantages:

• Visibility and transparency: with everything located in one place, it’s easier to search across the entire business’s code; the code is more discoverable. This can increase developer awareness of code used by other departments, and how it might support their own work. If a chunk of code could be re-used, or if an error is suspected, it’s easy to find and address. 
  
• Supports team collaboration: a more unified vision and collaborative outlook can be fostered. Ideas may spread between different project teams, and code sharing can help reduce replication of effort. A truly collaborative culture, of course, requires much more to truly take root. For example, investment in tools such as a suitable conferencing service can help, as does an emphasis on strong relationships.
  
• Coherence across the body of code: implications of changes in one area may be actioned more efficiently elsewhere, or across the entire body of code. Change management can become more holistic, encouraging implications elsewhere to be considered more fully. Conversely, where code is more divided, this may be weaker, and a technical debt may accrue, meaning code can get left behind.
  
• Refactoring: refactoring code–improving the code itself without changing its external behavior–can be carried out more easily.
  
• Standardization: the mono-repo approach encourages a more united and standardized coding style, streamlining the entire process. It can potentially embody high collaboration, communication, and consistency for teams.   

Disadvantages

While the advantages are significant, the Git mono repo approach also has potential drawbacks, especially as the business scales.

• Overwhelming for developers: with everything in one place, the amount of code can be truly gargantuan. Indeed, for new or inexperienced employees, there’s a danger that it could be overwhelming. Proper onboarding and lines of support are crucial for managing risk with this approach.
  
• Technically overwhelming: an increasing volume of code can pose technical challenges and strains as a mono repository grows.  One common problem is an IDE lag. Likewise, Git can quite quickly become painfully slow as a mono repo grows. Without the right tools, a vastly expanding mono repo can become cumbersome.

• Longer build times: as the volume of coding expands, build times can also be greatly lengthened, once again slowing things down.
  
• Ownership: if everyone has access to everything, ownership can be muddied. Clear hierarchies and protocols are needed to address this.
  
• Broken code: the Git mono-repository approach has risks. With everything in one place, a mistaken commit in one project can impact the entire body of code. This can bring development work screaming to a halt (cue developers across the business scratching their heads, wondering what they did wrong.)
  
• Risk of tight coupling: while mono repositories can help with consistency, this can, in turn, make it tempting to implement tight coupling, potentially leading to further problems and unnecessary dependencies.

Many of these disadvantages can be solved through the development and business-wide adoption of various tools. This is how the tech giants have been able to successfully adopt a mono-repository approach despite their size.

But developing and rolling out such enterprise tools takes considerable time and investment. It may be beyond the scope of many smaller and mid-size businesses. What works for Google will not necessarily work for all.

Git Multi Repo: Pros & Cons

This is where code is split across separate storage locations in Git. The number of repositories may vary, perhaps one per project. For example, you might have one for a team working on software that helps in showing how to record a cell phone call, and another for a conferencing services project. Depending on their role at the organization, developers might work within a single project repository, or across several.

Advantages

The Git multi-repo approach can offer advantages, especially as an enterprise scales from small beginnings.

• Easier to manage: as noted in the above section, a growing volume of coding can cause problems (e.g., how Git can slow as a repository scales up). Without tools to address this, a company may shift to multi repositories to make things more manageable. This is what Uber decided to do as it grew from a small to  a mid-sized company.
  
• Clear, transparent ownership: with this approach, as a developer, it’s very clear what areas of the code you own. It can be simpler to focus on your particular project goals. Access levels can be clearly defined by the repository structure itself. 

• Breakages are isolated: if a developer introduces an accidental error to the code, it only impacts code in that particular repository – not across the entire business. A mistake is less likely to bring all development grinding to a halt.

• Safer for less experienced and less integrated developer teams:  more limited, logically defined repositories may be safer for less experienced developers. Likewise, if there’s not a good culture of collaboration and dialogue between developer teams, a more delineated approach may be smoother. 

Disadvantages

Businesses do need a certain volume of code in order for multiple Git repositories to be sensible. For very small businesses or start-ups, it may not make sense to split up a relatively small amount of code. For them, a mono repository may seem the obvious way to start. But, as we’ve just seen, as businesses scale up, multiple repositories can offer advantages.

Yet, as the multi-repo business continues to grow, the issues below may emerge. Those businesses may consequently wonder whether it’s time to shift (or revert) to a mono-repo approach.   

• High overheads as a business grows: as the business grows, so can the overheads of managing a multi-repository approach.  

• Protracted and demoralizing workflows: under a multi-repo approach, small changes in one place can be more cumbersome to carry through elsewhere. Making edits across multiple repositories creates long-winded and annoying workflows. As well as being inefficient, that could be an employee unproductivity problem waiting to happen

• Silos and disunity: there’s a risk of fostering insular teams with little broader awareness. Opportunities for fruitful collaboration may be lost, and efforts may be replicated. Teams may move in different directions, leading to inefficiency, inconsistencies, and a lack of unified drive. 

• Dependency muddle: without the standardized, source-of-truth offered by a mono repository, major dependency headaches can ensue. 

Git Multi Repo Tool

If you’re looking for a Git multi repo tool to help you manage multiple repositories, GitKraken Client has a feature that allows you to do just that. Workspaces provide the ability to group multiple repositories under one Workspace, and allows teams to share Workspaces with new team members for easy onboarding. 

Furthermore, you can even take action across multiple repositories at the same time using Workspaces in GitKraken Client, like quickly filtering for all pull requests that are “at risk” due to inactivity, as shown below. 

Choose the Best Git Repo Size for You

There’s no easy answer to the Git mono repo vs Git multi repo debate. Ultimately, the optimum decision depends on each particular business. 

Moreover, as a business evolves, new challenges may make yesterday’s solution appear like part of the problem today. Your business may start small, but fast forward ten years, and you’ve gone global, your architecture requirements are bound to also evolve.

Consider Uber’s journey from mono repo to multi repo and then back again to mono. The final shift back made absolute sense once Uber was rich enough to invest in the tools required to overcome the disadvantages of a mono-repository approach. Yet not many companies will reach that scale or position, so it’s important to focus on the unique needs of your business

Crucially, there are many hybrid approaches out there, where businesses use a combination of mono or multi repositories. A business may have one mono repository for a certain range of projects or operations, plus perhaps a range of multi repositories for other particular projects. 

A pragmatic approach is perhaps best, as evidenced by the experiences of many businesses. Don’t just look at what businesses you may admire are doing now. Consider their entire journey, the dilemmas they faced, and the decisions they made. Each organization needs an approach that’s tailored to its own culture and resources. This is to support its various evolving projects and may require a hybrid approach.