Advantages of monolithic version control
Using multiple repositories seems like the most natural workflow to have. It&#x27;s easy to make a new one; it&#x27;s lightweight to do, and it allows your code base to scale naturally. You can set permissions for each repository, so if you did include some sensitive code within one repository or another, it&#x27;s easy to narrow the access to them. (Yes, don&#x27;t include sensitive code in a repository—but in an early-stage company, you or your engineers may not know that.)<p>Multiple repositories make for a forgiving structure for your code base. You can tailor them however you like.<p>But once you have a _lot_ of code, they become hard to manage. I see the utility of a monolithic repository there—now you know exactly where all your code is: it&#x27;s in this one repository!<p>Package managers mitigate a lot of the trouble with pulling in internal dependencies from other repositories. Nowadays, most languages have a package manager that can work with a private codebase, so monorepos aren&#x27;t necessary to help with that. But monorepos can help if you have a ton of versions floating around and you don&#x27;t want to support version 1.5.x of libjohnny when it&#x27;s now on 4.3.x. Your code either works with libjohnny as it is right now, or it doesn&#x27;t. (Which in turn makes it very clear to you how important it is to manage API-breaking changes!)<p>This feels a little bit rambling, but my thought is that there is some analogy between monorepos and microservices; don&#x27;t use them until you _need_ to use them! You&#x27;ll know it when you get there.