Is there anything GitHub doesn't do?
Many projects developed for a LAMP stack use the mainstay of subversion for version control. It's been a while since I've heard of anyone still using CVS and most LAMP projects haven't yet moved to git. As I'm a dual PHP/Ruby on Rails
developer I've jumped the fence and now use git for hosting all
projects (except for the ones at my current contract where subversion
is still the department standard). There are many reasons
why git is better than other version control systems, but in this
article I'm just going to talk about one particular git host - GitHub.com and what makes it so great.
Disclaimer
I don't work for GitHub.com, I don't know any of the developers personally (of course, I've heard of them) and have no vested interest in the success of their company. I'm just a user that is very satisfied with their offering and wanted to put my opinion on the web in case it helps someone else make the decision to use their services.
Simple creation of repositories
GitHub allows you to quickly create a new repository through a simple web interface. Actually, that's not strictly true - the web interface merely sets up the glue so that a given git repository pushed to their server will show in your account. The interface then shows a set of simple steps in order to create your repository locally and push it up to the server. One thing they do for you though is allow you to automatically import a subversion repository from their web interface. This can take a while (as it brings in all the history from the repository) but is an excellent way of quickly switching to git.
Forking
Let's say there is an existing repository you already use in one of your projects, say you have a plugin that someone's distributing on GitHub or some ruby gem and you want to make some changes to this project. The traditional way of doing this would be to check out the repository, make your custom changes and then email a diff to the maintainer. GitHub makes this process a whole lot simpler - all you do is fork the project on GitHub (which effectively clones it in to your GitHub account), develop your changes and then send a request to the maintainer to pull your changes. It's all very simple button-clicky style but makes it really easy to get your own copy of their code with your changes and submit them back. You can also then add their repository as a remote host into your local checkout and use a simple git command to pull their changes down into your repository - keeping your changes on top of any new work from upstream.
This is such a turnaround from the old days when the old saying was "Don't do that, you'll end up forking the project" - now it's the accepted norm and considered to be a good thing.
Web Hooks
As Github.com is a decent web interface to git, it wouldn't be complete without a way of creating web hooks to be able to make various web requests upon certain actions taking place (e.g. you may want to send a request to your ticketing web interface after a commit so it can parse the commit message and update the ticket). The flexibility of this is so powerful for integrating external systems to make it one seamless experience.
Downloads
If you tag your project with release numbers, git will automatically list your tags on the downloads page of you project along with simple links to download that particular version as a zip file or gzipped tar archive. This makes distributing your project to people who aren't that technical (i.e. can't or don't want to learn git) very easy. You can also put other files up in to your project and have download links to them too (e.g. user manuals, images).
README files
If you have a README file in the root of your repository, GitHub will automatically include the contents of that file at the bottom of your project's root listing. Even better, if you have it in RDoc or Markdown format (or a couple of others) it will parse it and display a rich text version. This is great if your project is small as you can include a quick introduction and a code sample and have it looking very neat.
Of course, if your project is larger you may want to use Github's wiki feature to create more of a body of content.
What about if it's bigger than a wiki (say you have full/complete API documentation)... Well...
Pages
This is one of those features that isn't really promoted on Github's dashboard or main page and I only found this today, but it's incredible. If you create a repository called {your_username}.github.com in your account (it's just a normal repository) and put an index.html file in there it'll be served as a web page at http://{your_username}.github.com/. Likewise you can add images, stylesheets, etc, etc and have a full web site content delivered by Github. Although it's only for static website content, you can use something called Jekyll to separate your header/footer from the main content and include it. Of course you could also just write a simple generator yourself that creates the static content.
If you want to have web sites per project this capability is provided for as well - just create a gh-pages branch of your project and include static files as above in that branch and it will be accessible at http://{your_username}.github.com/{your_project}/. This means you can host your website using a decent version control system in the same place as your code. If you don't want to use http://{your_username}.github.com/ and have a paid account (that's right folks, up to this point everything in github is available with the free accounts) you can create a file called CNAME and put a CNAME that the site should listen for.
Gists
The final nugget I find useful is Gists. If you've ever used a site like Pastebin or Caboose's version Pastie then you'll know how useful it can be to put snippets of code online for discussion. However, what then happens, as a result of your discussion, when you need to change the code and send an amended version? Easy, you go through the process again. This is where github add's it's magic and if you're using Github's gists you'll amend the existing code and it will keep a version history on the side for you, so you can both easily flick back to previous versions during your discussion.
9 Comments so far
Tim wrote on 04 March 2009 at 23:05
Wow, I wasn't aware github supported importing svn repositories - this is really useful and will hopefully help to spread git.
There is another project like Jekyll called staticmatic (http://staticmatic.rubyforge.org/). The best about it being it is structured like a rails app, and lets you write your templates / css in Haml and Sass, which you may or may not like but I find very neat.
Andy Jeffries wrote on 04 March 2009 at 23:10
@Tim even if GitHub didn't support it, you could do it on your machine as git supports importing from svn. However, I don't think it handles automatic linking of svn:externals (which is quite a problem for IPC).
I like HAML/SASS, but I tend to stick with ERB and normal CSS. I haven't done anything with GitHub Pages yet, I only found out about it today :-) It's now on my list of things to do... :-)
Paul Ardeleanu wrote on 04 March 2009 at 23:50
Hey,
Very good article!
Maybe one thing it does not do easily is explore the history of one single file - but that's probably because it's quite expensive to do in git.
What's happening @IPC? I've heard that Roy is also looking for a contract! Is recession hitting?
Andy Jeffries wrote on 05 March 2009 at 08:56
@Paul the reason is that git doesn't track files, it tracks content. It's been said a number of times, but it's really true. For more information you can see this link:
http://blog.endpoint.com/2009/02/git-it-in-your-head.html
They're replacing all contractors with permies. We're all off (some sooner than others, but still...). If you hear of any interesting contracts, let me know ;-)
Scott Chacon wrote on 07 March 2009 at 06:43
Thanks for the kind words, Andy. We appreciate the encouragement and I'm glad to know you like it so much.
@Paul - actually, we do provide tools for exploring the history of a single file. If you go to the page for a specific file such as:
http://github.com/wycats/dm-core/blob/master/lib/data_mapper.rb
you should see links titled 'blame' and 'history'. Clicking 'blame' will show you the file annotated by the last author/commit that edited each line in the file and allows you to drill down on any line to the commit that edited that line before that. Clicking 'history' will show you every commit that introduced changes to that file.
It is relatively more expensive to do in Git than in file-centric SCM systems, but it's not that bad, especially in normal sized projects. The blame functionality even runs pretty quickly on files in projects like Perl, which has a good 20 years of history it has to look through.
Thanks again, and I hope we can get together for a beer or something when PJ and I are in the UK (Scotland on Rails and gitlondon.com) in a few weeks.
Paul Ardeleanu wrote on 09 March 2009 at 06:51
Andy,
It's true that Git tracks content... I just wish Github invented a clever way to track changes to a file - this is especially useful if you store unrelated files in the same repositories (e.g. articles one writes).
Paul Ardeleanu wrote on 09 March 2009 at 06:54
I should have read Scott's comment as well:)
@Scott Thanks! I'll give that a go!
Stephen wrote on 31 July 2009 at 05:32
>Is there anything GitHub doesn't do?
I laughed when I read this title, because the first (/cynical/) thought that popped into my head was "WORK! It doesn't work."
I'm at work sitting behind a proxy/firewall, and i've spent something like four hours trying to workout how to get around this error:
scarmody@AU23WS000000281 ~/My Documents/programming/gith-stephencarmody/github-c
ontest-2009 (master)
$ git push origin master
ssh: connect to host github.com port 22: Bad file number
fatal: The remote end hung up unexpectedly
scarmody@AU23WS000000281 ~/My Documents/programming/gith-stephencarmody/github-c
ontest-2009 (master)
$
I know its got to do with the proxy/firewall blocking whatever, I've googled and tried a few suggestions, but nothing is working.
I'm currently using google subversion repository, which I haven't had a problem with from home or from work.
If I can't use the (/expletive/) thing from an environment I spend eight hours a day at, then there is no way I can migrate over.
So "Is there anything GitHub doesn't do?", well yes pretty much is don't do anything.
Scott Chacon wrote on 03 August 2009 at 15:59
@Stephen - it is unfortunate that your company doesn't allow SSH outgoing access. It's relatively rare but it does happen, so we've provided a workaround for that which is that we have a SSH server listening on port 443 at ssh.github.com, since 443 is almost always allowed through corporate firewalls. You can find a few articles on how to setup SSH to work via this here:
http://github.com/guides/dealing-with-firewalls-and-proxies
Sorry this is difficult, but it's not really an issue with GitHub or Git but with your company it's policies toward SSH. The easiest fix for this is to get your company to open up outgoing port 22 access.
Click here to have your say...