What is the current definition of a Mono-Repo

Facebook famously made a post about using a "monorepo" and for a while it seemed like this approach would take over from standard, separate out the code into multiple source controlled "repositories". but there has never really been much information made public about the actual approach used. Previously we have had this question : Why does Meta (Facebook) use mono-repo in their source control? To which I gave the answer that; to the best of my knowledge and previous investigations "monorepos" were really just attempts to solve problems with Perforce style source control where branching and merging have issues you don't see (as much) in git, using quite complicated custom build tools and conditional compilation of parts of the solution. (0 votes) Where as, at least at the time, I found people using the term to mean, "just put all the code in one git repo and build it". An approach I think Ben Cottrel, sums up in his comment: Separate repos are only a good idea if it results in true isolation. I have worked on too many code bases where a simple behavioural change to a requirement has involved changing 10+ different git repositories, each with their own versioning, tests, interfaces and pipelines, therefore requiring separate PRs, all to happen in the correct order; essentially turning a 30-minute software change into something which takes all day. Mono repos are preferable to this This is fine, and you can see there is a balance to be made about when and what to split in any solution. But if mono-repo just means "don't prematurely split a repo" it's not a revolutionary thing to blog about. Has the idea of monorepos taken off? what does the term mean these days, has it solidified into a single approach or competing ones and is it compatible with git? Please answer with an explanation of the idea, the problem it solves, how it is implemented and what situations it is applicable to?

Jun 12, 2025 - 06:20

Facebook famously made a post about using a "monorepo" and for a while it seemed like this approach would take over from standard, separate out the code into multiple source controlled "repositories". but there has never really been much information made public about the actual approach used.

Previously we have had this question : Why does Meta (Facebook) use mono-repo in their source control?

To which I gave the answer that; to the best of my knowledge and previous investigations "monorepos" were really just attempts to solve problems with Perforce style source control where branching and merging have issues you don't see (as much) in git, using quite complicated custom build tools and conditional compilation of parts of the solution. (0 votes)

Where as, at least at the time, I found people using the term to mean, "just put all the code in one git repo and build it". An approach I think Ben Cottrel, sums up in his comment:

Separate repos are only a good idea if it results in true isolation. I have worked on too many code bases where a simple behavioural change to a requirement has involved changing 10+ different git repositories, each with their own versioning, tests, interfaces and pipelines, therefore requiring separate PRs, all to happen in the correct order; essentially turning a 30-minute software change into something which takes all day. Mono repos are preferable to this

This is fine, and you can see there is a balance to be made about when and what to split in any solution. But if mono-repo just means "don't prematurely split a repo" it's not a revolutionary thing to blog about.

Has the idea of monorepos taken off? what does the term mean these days, has it solidified into a single approach or competing ones and is it compatible with git?

Please answer with an explanation of the idea, the problem it solves, how it is implemented and what situations it is applicable to?