Google's Monolithic Repository

In the early days of Google, a small team of engineers made a decision.

A decision that would shape the company’s future.

They chose to store all of their code in a single, monolithic repository.

As Google grew into a tech giant, the codebase grew exponentially.

From its original home in Perforce to a custom-built system called Piper.

But with great size came great challenges.

How could thousands of developers work on the same codebase without descending into chaos?

“𝗧𝗿𝘂𝗻𝗸-𝗯𝗮𝘀𝗲𝗱 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗺𝗲𝗻𝘁”

Like a massive tree, the codebase had a single trunk, with developers working directly on it rather than creating branches.

To take care of this enormous code trunk, Google created specialized tools:

📌𝗖𝗶𝘁𝗖, a cloud-based workspace system, allowed developers to work on any part of the codebase without needing to download its entirety.

📌𝗖𝗿𝗶𝘁𝗶𝗾𝘂𝗲 ensured that every change was carefully reviewed before being merged into the trunk.

📌𝗧𝗿𝗶𝗰𝗼𝗿𝗱𝗲𝗿 constantly analyzed the code for potential issues.

📌And when large-scale changes were needed, 𝗥𝗼𝘀𝗶𝗲 coordinated massive refactoring efforts across millions of files.

Initially, people thought that “trunk based development” wouldn’t work.

Critics said that it would eventually collapse under its own weight.

But Google knew that its benefits - unified versioning, extensive code sharing, and simplified dependency management - far outweighed its costs.

By 2015, the repository contained over a billion files and two billion lines of code.

It became a testament to Google’s collaborative culture.