Originally we just wanted to make a git hosting site.In fact, that was the ﬁrst tagline.
git repository hostinggit repository hosting.That’s what we wanted to do: give us and our friends a place to share git repositories.
a brief historylet’s start with a brief history
It’s not easy to setup a git repository. It never was.But back in 2007 I really wanted to.
I had seen Torvalds’ talk on YouTube about git.But it wasn’t really about git - it was more about distributed version control.It answered many of my questions and clariﬁed DVCS ideas.I still wasn’t sold on the whole idea, and I had no idea what it was good for.
CVS is stupidBut when Torvalds says “CVS is stupid”
and so are you“and so are you,” the natural reaction for me is...
At the time the biggest and best free hosting site was repo.or.cz.
Right after I had seen the Torvalds video, the god project was posted up on repo.or.czI was interested in the project so I ﬁnally got a chance to try it out with some other people.
Namely this guy, Tom Preston-Werner.Seen here in his famous “I put ketchup on my ketchup” shirt.
I managed to make a few contributions to god before realizing that repo.or.cz was not different.git was not different.Just more of the same - centralized, inﬂexible code hosting.
This is what I always imagined.No rules. Project belongs to you, not the site. Share, fork, change - do what you want.Give people tools and get out of their way. Less ceremony.
So, we set off to create our own site.A git hub - learning, code hosting, etc.
We started with the code browsing and commit viewing...
But once we added the current version of the dashboard, we knew this was different.
And eventually “git repository hosting” gave way to “social coding”
Unleash Your Code Join 500,000 coders with over 1,500,000 repositoriesWhat’s special about GitHub is that people use the site in spite of git.Many git haters use the site because of what it is - more than a place to hostgit repositories, but a place to share code with others.
2007 octoberThe ﬁrst commit was on a Friday night in October, around 10pm.
2008 januaryWe launched the beta in January at Steff’s on 2nd street in San Francisco’s SOMA district.The ﬁrst non-github user was wycats, and the ﬁrst non-github project was merb-core.They wanted to use the site for their refactoring and 0.9 branch.
2008 aprilA few short months after that we launched to the public.
Along the way we managed to pick up Scott Chacon, our VP of R&D
the web siteAs everyone knows, a web “site” is really a bunch of different components.Some of them generate and deliver HTML to you, but most of them don’t.Our site consists of four major code “frameworks” or “apps”
railsWe use Ruby on Rails 2.2.2 as our web framework.It’s kept up to date with all the security patches and includes custom patches we’ve addedourselves, as well as patches we’ve cherry-picked from more recent versions of Rails.
railsGitHub is about 20,000 lines of Rails code, not counting Rails itself, plugins, or gems.
We found out Rails was moving to GitHub in March 2008, after we had reached out tothem and they had turned us down.So it was a bit of a surprise.
rails pluginsWe currently have 27 Rails plugins installed, and that number is always changing.
smokeKinda.Eventually we needed to move of our git repositories off of our web serversToday our HTTP servers are distinct from our git servers. The two communicate using smoke
smoke“Grit in the cloud”Instead of reading and writing from the disk, Grit makes Smoke callsThe reading and writing then happens on our ﬁle servers
bert-rpcRather than use Protocol Buffers or Thrift or JSON-RPC, Smoke uses BERT-RPC
bert-rpcwe have four ﬁle servers, each running bert-rpc serversour front ends and job queue make RPC calls to the backend servers
mojombo / bertrpcYou can grab bert-rpc on GitHub
mojombo / bertOr if you just want to play with BERT
chimneyWe have a proprietary library called chimneyIt routes the smoke. I know, don’t blame me.
chimneyAll user routes are kept in RedisChimney is how our BERT-RPC clients know which server to hitIt falls back to a local cache and auto-detection if Redis is down
chimneyIt can also be told a backend is down.Optimized for connection refused but in reality that wasn’t the real problem - timeouts were
proxymachineAll anonymous git clones hit the front end machinesthe git-daemon connects to proxymachine, which uses chimney to proxy yourconnection between the front end machine and the back end machine (which holdsthe actual git repository)very fast, transparent to you
mojombo / proxymachineproxymachine can be used to proxy any kind of tcp connectionopen source
sshSometimes you need to access a repository over sshIn those instances, you ssh to an fe and we tunnel your connection tothe appropriate backendTo ﬁgure that out we use chimney
master / slaveAll reads and writes go to the masterWe use the slave for backups and failover
cachingOn the site we do a ton of cachingusing memcached
fragmentsWe cache chunks of HTML all overUsually they are invalidated by some action
fragmentsFormerly we invalidated most of our fragments using a generation scheme,where you put a number into a bunch of related keys and increment itwhen you want all those caches to be missed (thus creating new cacheentries with fresh data)
fragmentsBut we had high cache eviction due to low ram and hardware constraints, and foundthat scheme did more harm than good.We also noticed some cached data we wanted to remain forever was being evicted dueto the slabs with generational keys ﬁlling up fast
pageWe cache entire pages using nginx’s memcached moduleLots of HTML, but also other data which gets hit a lot and changes rarely:
page- network graph json- participation graph dataAlways looking to stick more into page caches
objectWe do basic object caching of ActiveRecord objects such asrepositories and users all over the placeCaches are invalidated whenever the objects are saved
associationsWe also cache associations as arrays of IDsGrab the array, then do a get_multi on its contents to get a list of objectsThat way we don’t have to worry about caching stale objects
walkerWe also have a proprietary caching library called Walker
walkerIt originally walked trees and cached them when someone pushedBut now it caches everything related to git:
optimizationsSo what other optimizations have we done
asset serversWell we do the common trick of serving assets from multiple subdomains
asset serversassets0.github.comassets1.github.comand so forth
sha asset id/css/bundle.css?197d742e9fdec3f7/js/bundle.js?197d742e9fdec3f7Now simple code changes won’t force everyone to re-download the css or js bundles
scripty 301Again, for most of these tricks you need to really payattention to your app.One example is scriptaculous’ wiki
scripty 301When we changed our wiki URL structure, we setup dynamic 301 redirectsfor the old urls.Scriptaculous’ old wiki was getting hit so much we put the redirect into nginx itself -this took strain off our web app and made the redirects happen almost instantly
ajax loadingWe also load data in via ajax in many places.Sometimes a piece of information will just take too long to retrieveIn those instances, we usually load it in with ajax
If Walker sees that it doesn’t have all the information it needs, it kicks off a jobto stick that information in memcached.
We then periodically hit a URL which checks if the information is in memcached or not.If it is, we get it and rewrite the page with the new information.
test unitWe mostly use Ruby’s test/unit.We’ve experimented with other libraries including test/spec, shoulda, and RSpec, but in the endwe keep coming back to test/unit
git ﬁxturesAs many of our ﬁxtures are git repositories, we specify in the test what shawe expect to be the HEAD of that ﬁxture.This means we can completely delete a git repository in one test, then have it back inpristine state in another. We plan to move all our ﬁxtures to a similar git-system in the future.
stagingWe also always deploy the current branch to stagingThis means you can be working on your branch, someone else can be working on theirs,and you don’t need to worry about reconciling the two to test out a featureOne of the best parts of Git