When and whether to split up a project into smaller repositories?

<p>I have a question about project separation in Go, and if there are any established best practices in terms of separating your project across multiple repositories vs going with a monorepo approach.</p> <p>I&#39;m working on an application which currently consists of a single repository with three main parts, each of which has multiple packages under it: a server, a client, and a &#34;core&#34; (where various packages that both the server and client might use live, including my domain types). </p> <p>At what point should I consider splitting these into three different projects entirely and storing them all in their own repository? My reasoning is that I&#39;m building this with the expectation that there will be more clients added which make use of my server&#39;s API, and it feels potentially cleaner to create a more clear-cut separation between these three distinct parts of my overall project &#34;environment&#34;. I can see myself creating <em>many</em> more clients and little standalone tools which communicate with the server to help with debugging, analysing the data, etc. </p> <p>But am I just over-complicating things if I split this up into multiple repos now, making my day-to-day work more fiddly by creating the need for three different CI setups, three different test coverage reports, switching between three different repos in my IDE, etc? I&#39;m looking for a good long-term approach.</p> <hr/>**评论：**<br/><br/>Ploobers: <pre><p>I&#39;m a big fan of the mono repo. You can separate things with folder structures, and by sprinkling in some internal folders, even enforce better separation of concerns than a repo would provide.</p> <p>Here&#39;s a good discussion of the topic from Digital Ocean: <a href="https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a-scalable-repo/" rel="nofollow">https://blog.digitalocean.com/cthulhu-organizing-go-code-in-a-scalable-repo/</a></p></pre>014a: <pre><p>I actually think, in general, <em>small</em> teams use multiple repos, and as you get bigger you start preferring the monorepo style. Google, Microsoft, Facebook, they&#39;re all on monorepos. </p> <p>The main reason I would argue against a monorepo is ease of setting up a deployment pipeline.</p> <p>With a &#34;one deployment &lt;- one artifact &lt;- one CI trigger &lt;- one repo&#34; structure, it all just works. Once you turn &#34;one repo&#34; into &#34;multiple artifacts&#34;, you need to answer questions like &#34;how can the CI know when to just build artifact X versus all of the artifacts in the repo&#34;. Which means more tooling to detect where the file changes happened. Its not impossible, but its harder, and small teams don&#39;t need &#34;harder&#34;.</p> <p>Another one is that, especially with Go, its <em>too</em> easy to not follow best practices when importing code from elsewhere in the monorepo. Large teams often have a bunch of testing and great human reviewers. Small teams don&#39;t. So there&#39;s less stopping someone from throwing a new module in <code>repo/internal/left-pad</code>, importing that from somewhere random, not following good versioning rules, essentially just not following the process. Nothing replaces enforced processes, but separate repos add natural barriers. Its easier to catch a new <code>left-pad</code> repo on Github than to follow every PR when teams start scaling up.</p> <p>But do what works for your team. As I said, I prefer monorepos at any scale. Being able to pull all your changes across your entire product in one <code>git pull</code> is huge. Being able to track PRs across your product in one interface on Github is huge. If you have the tooling capability to execute on a monorepo, I believe its the best choice for any organization, not just Go.</p></pre>ionrock: <pre><p>I could be wrong by my understanding is that many big name monorepo users actually started from different systems. Google used to use perforce at one point and Microsoft used its own VCS. Facebook also started with SVN (I think!) and later migrated to mercurial. The point being is that these companies already had an investment in a monorepo and VCS that likely made breaking this up more trouble than it was worth. That is especially true when they didn&#39;t start with repository management tools like Github that provide an API across a variety of repos. </p> <p>Also, we use a monorepo, but it has its downsides. Daily development is slower, CI is slower and we&#39;re starting to hit performance limits on our Github instance because the unit of operation is a repo. Therefore, with most systems supporting the single repo == single artifact model, there is a lot to gain by keeping thing separate and capitalizing on the repo management tooling, like Github, to enforce consistency.</p> <p>All that said, I&#39;d let deployments and project automation guide decisions of when you should break up a repository. If it seems like you&#39;re writing a ton of code to manage your build and project tasks, then break things up and use your current project automation as a standard. </p></pre>