The largest Git repo
At Sun Microsystems, Inc., (RIP) we have many &quot;gates&quot; (repos) that made up Solaris.  Cross-gate development was somewhat more involved, but still not bad.  Basically: you installed the latest build of all of Solaris, then updated the bits from your clones of the gates in question.  Still, a single repo is great if it can scale, and GVFS sounds great!<p>But that&#x27;s not what I came in to say.<p>I came in to describe the rebase (not merge!) workflow we used at Sun, which I recommend to anyone running a project the size of Solaris (or larger, in the case of Windows), or, really, even to much smaller projects.<p>For single-developer projects, you just rebased onto the latest upstream periodically (and finally just before pushing).<p>For larger projects, the project would run their own upstream that developers would use.  The project would periodically rebase onto the latest upstream.  Developers would periodically rebase onto their upstream: the project&#x27;s repo.<p>The result was clean, linear history in the master repository.  By and large one never cared about intra-project history, though project repos were archived anyways so that where one needed to dig through project-internal history (&quot;did they try a different alternative and found it didn&#x27;t work well?&quot;), one could.<p>I strongly recommend rebase workflows over merge workflows.  In particular, I recommend it to Microsoft.