What version control system does Facebook use?

James Ide, Worked at Facebook in 2009 The main repository uses Subversion and engineers can use a svn-to-git bridge if they wish, allowing them to create their own branches.

Steven Grimm's answer to Does Facebook use feature branching? describes how git is used in the context of the master Subversion repository at Facebook:

Most developers use git locally, and many of us make extensive use of git's local branching capabilities to manage our work. Some teams use git's distributed version

control capabilities to propagate changes to each other without committing to the central Subversion repository.

There are some smaller code bases that solely use git, but Subversion houses the most code; see Evan Priestley's answer to How large is Facebook's codebase?.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Does Facebook use feature branching? Do most new features get developed on a private branch for weeks or months before the first commit to Trunk, or are most features built directly on Trunk?

Steven Grimm, 2005-2012 I'll limit myself to the Web frontend code base here since you specified "new features" by which I assume you don't mean "new backend features that aren't visible to

users."

If you're talking strictly about what gets checked into our master Subversion repository, then the answer is that everything is built directly on trunk. Up until a

couple years ago, we occasionally used Subversion branches for major changes such as UI overhauls, but merges were too error-prone and time-consuming so we pretty

much stopped doing it. At this point we use Subversion branches for release management but not for development.

Instead, we use a system that lets us do low-cost gating of different parts of the code base based on various criteria such as user ID whitelists, IP address ranges,

which language the user is using, and so on. A new feature will be checked into trunk but it will be isolated behind a permission check such that end users won't

execute any of the code. This is essentially a continuous-integration setup, which forces us to resolve conflicts early and often during development so they don't

turn into major headaches.

And it ends up having advantages above and beyond cutting down on merge issues. During initial development a team will typically add itself to a whitelist so they

can try out their work in progress without disturbing anyone else. Then once it's ready for broader testing, the permission settings will be changed to allow access

by all Facebook employees. As the public launch approaches, we can selectively roll the feature out to a small percentage of the user base to gather feedback and

usage statistics. If things go haywire we can quickly shut off the feature without having to push new code.

However, it's not quite as cut-and-dried as "we never use branches." In the strictest sense, of course, developer sandboxes are branches in and of themselves. Less

pedantically: Most developers use git locally, and many of us make extensive use of git's local branching capabilities to manage our work. Some teams use git's

distributed version control capabilities to propagate changes to each other without committing to the central Subversion repository. This practice isn't widespread

but it does happen; I've done it on occasion.

But in general, such use of branches is pretty short-lived and anything that gets pushed to the production site will have been checked directly into trunk from the

point of view of the central repository.

The situation is different for some backend components; traditional branching is used more heavily on the ones that are backed by Subversion, and some of them are

natively hosted in git where branching is a lot more lightweight.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ How large is Facebook's codebase? Evan Priestley, Worked at Facebook from 2007-2011 The site itself is around 9.2M lines as of a few minutes ago, but this excludes numerous backend services so the actual size is significantly larger. There are so

many components that it would be difficult to accurately count everything, but the main site codebase is the largest by far so this is at least a reasonable order-

of-magnitude estimate.