The latest evolution in social revision control

If you do any complicated development, especially with a couple people, a revision control system (RCS) is essential. Basically, RCS allows you to have a central location that stores all the changes ever made to a project (the repository) and users can send updates that are tacked onto the list of changes to a file (usually called committing changes). If you realize that you made a mistake in your current project, you can always 'rewind' the file to a previous date. You can also have multiple people updating changes and the RCS will be smart about not letting one update bash another.

For a long time, everyone used CVS (Concurrent Versioning System). It was OK but had a lot of problems that would crop up when doing a lot of development. We got bit by the 'assume everthing is ascii' and 'all changes must be committed.' Also, there can only be one repository and if you lose the repository you lose all the historical data so the repository has to be taken care of and you have to be able to reach it if doing any commits (annoying if the CVS repo is on another site and say you dont have network connectivity or the site is down.)

We also used SVN for a brief time (but not enough to really have a strong opinion of it).

But then came along git and we really liked it. Three great things about it is that, first, you can commit and push to the repository as two seperate procedures. Second, git repositories are distributed, which means that every client has all the same data as the repository. So lets say your repository goes down or is deleted or lost, you can just make one of the clients into a repository. Third, you can rename and move files.

Anyways, so now we have a non-crappy RCS, hooray! But then to make it one better, github comes along!


There's a joke where every time someone says "wow github is awesome" all the other engineers roll their eyes and say "jeez where have you been for the last n years?" Having come from sourceforge, github does everything and does it great. We have a paid account so we can keep repositories private while they're being worked on. But many people can probably get away with a free account! The thing that really made it an easy decision is knowing that if we want, we can take the local copy of the repository and move it elsewhere so it's a riskless situtation.
I can't really get into all the excellent features of github because this article would be really too long but basically here are some of our super favorites!

Easy forking/edits & pulls

People can fork, edit and send pull requests (updates) very easily. We get one pull request a week of people with fixes and mods. It's a hell of a lot easier than dealing with emailed diffs. For example, here yvest fixed a missing function in our Nokia 5110 library. They forked the repository, made changes, tested and then sent us a pull request. After looking at the code we can press a button to merge it directly (or we can test it before pulling).
If I click on the commit it shows me the code diff very nicely!

Private repositories

Private repositories - for paid accounts. For example, while we're still working on a chunk of code, we usally keep it private until we know it's finished and working.

Social integration

Social integration with twitter/facebook/etc - You can have your repository tweet commits! How cool is that?

On-the-fly commits

You can edit/commit a file on the fly. So if there's a typo, you can do it right on the site instead of having to do a edit, save, commit, push. Very convenient! In this example, there was a typo where we meant to have a uint16_t and instead we had a uint8_t - easy to fix!

This guide was first published on Feb 27, 2013. It was last updated on Mar 08, 2024.

This page (GitHub) was last updated on Feb 20, 2013.

Text editor powered by tinymce.