Question

How do software companies use Git-based repositories like GitHub, GitLab, and other packages that handle version control?

Answer 1

At Microsoft, there's a movement to get onto Git from our ancient proprietary centralized version control system, and my impression is we're slowly but surely getting there. Open Source projects are hosted on Github, and proprietary projects are hosted in Git repos in Visual Studio Team Services.

Part of the reason that the migration is taking a while is that some code bases are way too big for Git to handle without slowing to a crawl. To deal with that, the VSTS team made the Git Virtual File System. Awesomely, they made it open source!

(note: I'm also not trying to speak for the whole company in any official way :) )

I've read about Facebook's use of Mercurial, so as of the last I've read they don't even use git. But I'd guess all of these companies use GitHub on some level. FB, for example does all of that open source stuff with GitHub, so I'd be curious about where they draw lines and choose where to do what.

Amazon as an organization is pretty modular - they have teams working on lots of different projects and technologies. While I would expect the CodeCommit team to be using CodeCommit, it wouldn't surprise me if other teams used other CVS systems. You can further splice that by teams on projects under AWS, teams that work on devices, teams that work on their shopping, teams that work on physical distribution, etc.

Google doesn't use GitHub, or Git. Instead they have their own, pretty insane system called Piper. There is only one Piper repository. Different projects are different subdirectories within the same massive repository.

As a result, there's no way to clone the entire repository to your computer. The standard way to handle this is something called Clients in the Cloud, or CitC. Basically the entire repository is mounted as a virtual filesystem, and you can do whatever you want with it.

It's not sane to try to fix merge conflicts in such a big repo. That problem is solved by (almost) eliminating branching or merging. Piper's branching support is very limited, and the only time it's used is for releases. Generally, there's only one branch.

There's also only one version of everything: the latest version. There's no old versions kept around for things that haven't updated to the new versions. If you make a backwards incompatible change to an API, you have to then go and update everything that uses your API. Which you can do, since everything's in the same repository. There are even automated tools you can use for this.

Version control is important for documents that undergo a lot of revision and redrafting and is particularly important for electronic documents because they can easily be changed by a number of different users. These changes may not be immediately apparent.