That’s the problem GoHub attempts to solve. It’s a tiny webserver (written in the Go language) that listens on a port for messages from GitHub’s WebHook API. Any time a commit is pushed to GitHub, they send a JSON notification to your GoHub listener, and it runs the shell script of your choice when the specified branch (usually “master”) changes.

The original GoHub script was created by adevan, but I made my own fork that includes some extra goodies. It includes a magical setup script that sets everything up for you, as well as an Upstart script. (Configurations and logs are also under /etc/gohub in the fork.) So if your Linux distro is still using SystemV instead of Upstart, you probably want to use the original instead of the fork. (At least until I get around to writing a SystemV script and amending the setup…) If you’re on Ubuntu, you’re good.

Assuming you already have Go installed, it’s a simple matter of cloning the repository and running the setup script.

git clone https://github.com/redwallhp/gohub.git
cd gohub
chmod +x ./setup
sudo ./setup

Then you need to add your watched repositories to /etc/gohub/config.json. Each object should specify the repository name (in the form of gohub not redwallhp/gohub), the branch (master in most cases) and the path to the shell script that should be run. The best place to keep them is in /etc/gohub/scripts, to keep everything together and save your sanity in the future.

What should one of those scripts look like? Here’s a super simple example that just takes the files checked out and copies them to the public directory the web server is looking in. This works well for PHP projects.

#!/bin/bash -l

GIT_REPO=https://github.com/me/awesomeapp.git
TMP_GIT_CLONE=~/tmp/git/awesomeapp
PUBLIC_WWW=/var/www/sites/awesomeapp

git clone $GIT_REPO $TMP_GIT_CLONE
cp $TMP_GIT_CLONE $PUBLIC_WWW
rm -rf $TMP_GIT_CLONE
exit

The README file has the script I use to build and deploy Jekyll sites.

Once you have everything set up to your liking, start the server by running service gohub start. This invokes the Upstart script and starts the server daemon.

Now all that’s left to do is add the WebHook on GitHub. Go into the settings for the repository, select Service Hooks, and then WebHook URLS. Paste in the appropriate URL, which follows this convention:

http://example.org:8392/reponame_branch

So if your repository URL is https://github.com/me/awesomeapp.git, and your domain is example.org, your WebHook URL would be http://example.org:8392/awesomeapp_master.

Save the settings on GitHub, and test out your new Git deployment system. If you make a change and push the commit, the changes should take effect momentarily.

Setup was a little bit of a hassle at first, due to some dependency issues with the development version I was trying to install. I would definitely recommend downloading the stable version from GitList.org. The installation instructions are simple enough, though the script seems to prefer having its own domain or subdomain. (GitList doesn’t use absolute URLs, and there is no documented configuration option to set a base directory other than the domain root.)

Once you get it up and running, it’s a convenient way to view commits. I’d probably be using it regularly if I wasn’t already hosting my private repositories on BitBucket.

Despite its usefulness, however, the initial learning curve puts off some people. It can be a little difficult to wrap your head around if you’re not already familiar with the concept of version control.

That’s where Try Git comes in. It aims to teach you the basics of Git with an interactive tutorial that features an in-browser command prompt. The tutorial walks you through different commands, and helps you see how everything works.

If you’re not using Git yet, check it out! And keep in mind that there are alternatives to GitHub if you don’t want to host your code publicly. You can use Git locally, on your own server, or a service like BitBucket that doesn’t charge for private repositories.

A fancy new one-page website has been circulating Twitter and Reddit of late, serving as an easy into to Git. Git: The Simple Guide helps you install the software, create a repository on your local computer or check out an existing remote one, and start using Git.

It’s a good tutorial, and the design looks great. I like the differently-colored segments with the large text and rounded styling on the <code> elements. (The page is actually hosted on GitHub Pages, which seems fitting, given the subject.)

While it does make sense to pay for a tool if you use it extensively for commercial purposes, you may not be ready to if you’re an indie developer just beginning a project that won’t hit the shelves for awhile. Also, if you’re using it for versioning and deploying websites, you may not want to have all of your source be public.

GitHub’s business model is primarily the sale of premium accounts with varying numbers of allowed private repositories, starting at $7/month for five private repositories and up to one collaborator. It’s not a bad deal at all, as GitHub is by and large open source projects, but you may still want to find a better offer. Fortunately, there are a couple of solid competitors.

BitBucket

BitBucket is very much like GitHub, functionally. It has the same sort of social collaboration tools, and most of the same features. But that’s where the differences end. Their pricing scheme is to give you all of the repositories you could possibly want, both public and private, while charging to add extra collaborators to your private repositories. You get five for free, and can upgrade to ten for $10/month, twenty-five for $20/month, etc.. Oh, and they support both Git and Mercurial.

I’ve been using BitBucket lately for some of my projects, and it’s been great so far.

Beanstalk

Beanstalk only does private repositories, offering plans limited by disk space and the number of repositories, as well as the number of authorized users. Aside from their 100MB single-repository trial plan, their offerings start at $15/month for 3GB of space, 10 repositories and 5 users. One of their unique selling points is their integration with tools like Basecamp and Lighthouse. They also have quite a few corporate customers.

After seeing the six thousandth post/comment/tweet raving about Git, another version control system, I decided to finally give it a closer look. The lightbulb finally clicked on. I now know what’s so special about Git.

Git, unlike, SVN is distributed. You can version your code entirely on your computer, only pushing to a server when you’re ready…if you’re using a remote server at all. When you commit changes, it’s still just updating the revision records on your local computer; you have to use a separate command to push the changes to the remote repository. This means if you’re working alone, without other contributors, you can version files without needing a special server hosting your code, although you lose the convenient off-site backup. This is great for small projects.

Then you have the Github service, with it’s magical socially-networked code repositories. Suppose you have an improvement upon an open source project hosted on Github. You just click a button to “fork” it, creating a new repository under your account with a copy of the original’s contents. You then pull the files down to create a working copy on your system, make your changes, and push them back to your Github repository. If the developers maintaining they original project like your changes, they can merge the changes in your repository back into the main one. That concept amazes me.

I think I’m starting to see why people rave about Git so much. I’ve been aware of it for awhile now, but the concepts didn’t quite “click” until recently.

Git seems like a powerful tool, and one I’d definitely like to look into in the future. It seems like it can do a bit more than SVN, as WhyGitIsBetterThanX.com happily points out, and may even be easier once you get used to it.

Git is a open-source code managemen tool; it was created by Linus Torvalds when he was building the Linux kernel. Because of those roots, it needed to be really fast; that it is, and easy to get the hang of as well. Git allows you to work on your code with the peace of mind that everything you do is reversible. It makes it easy to experiment with new ideas in a project and not worry about breaking anything.

Version control systems are great for anybody doing serious coding work, or design even. You could keep your blog’s theme in a repository, for example, so when you make changes to it you can roll them back if things break or you just want to revert back. You would be able to store the files remotely on a Git server, work on them locally (in your WAMP/MAMP server), and when you want to make you changes live you could just checkout the files to your production server.