Last week I popped open an outdated version of Filezilla, looked up FTP credentials for my ancient 1&1 hosting in a Google spreadsheet, then proceeded to overwrite every remote file on my site because I couldn't remember what was up-to-date. Then I cried. Deeply.

Fixing my hosting and deploy process has been on my todo list for months, but somehow consistently took a backseat to sexier projects. I'm happy to announce I finally addressed it and am now 100% hosted on Github.

Why it's awesome

• The deploy process is fantastically simple. I just push to a gh-pages branch and it's live in seconds.
• My version control and hosting are the same platform. This makes handling changes a snap.
• Easy deploys mean I'm more likely to address bugs/issues in a timely manner.
• It's free (unless you want private repositories).

The limitation

Github pages only serve vanilla HTML/CSS/JS, meaning if your project requires server-side scripting or a traditional database, you're out of luck. That said, greater numbers of projects and libraries are adopting compiled static assets and heavy client-side logic, so hopefully this isn't a crippling contrainst for most.

Get up and running with Github hosting

1. Create a branch off an existing github repo, name it "gh-pages", and push
2. Visit yourGithubUsername.github.com/reponame and voila!
3. To use a custom domain follow Github's instructions, but it basically requires placing a CNAME file in the root of the repo that points to a custom URL, then setting the matching domain's A-record to Github's IP address. (204.232.175.78)

Deploying in style

If your site is raw HTML/CSS/JS, deploying is as simple as merging any new changes from a working branch into the gh-pages branch and pushing. You're done. Changes to your site will be reflected almost immediately.

There are some more complicated situations though. For example, the blog you're reading has Ruby source files that are compiled to create static HTML/CSS¹. Since Github hosting doesn't support running Ruby, my gh-pages branch must be only the static HTML/CSS. Thus, my master branch is the Ruby source, while the gh-pages branch is only the compiled HTML/CSS.

The challenge then becomes how to merge newer, compiled files from the source branch into the gh-pages branch to be published? The brute force option would be for me to check out 2 instances of the "davegamache.com" repo, one on the master branch and the other on the gh-pages branch. I could work exclusively in the master branch and then drag-and-drop the updated, compiled site into the gh-pages instance when I was ready to publish.

While the copy-pasta approach absolutely works, I wanted something a bit less kludgy that didn't require me to check out multiple instances of a repo. My solution was to write a bash script² that did the work for me. Here's what it does:

1. Copies the compiled HTML/CSS from master into a temp directory outside the repo
2. Switches to the gh-pages branch and replaces old files with new ones
3. Does a 'git add -A' to add any new files
4. Runs a 'git status' so I know exactly what's changed before I push live

Here's the alias in full:

I have a similar alias for my Skeleton project. I keep source files in the master branch, while the documentation code lives in the gh-pages branch. Since the docs are built on the source (with some additional custom CSS), I use an alias to keep the docs up-to-date with the true Skeleton source from the master branch.

I love my new workflow

Using Github as a hosting provider is amazing. If you have projects built with vanilla HTML/CSS/JS (or that compile to static code), I strongly suggest giving Github pages a chance. Combining version control with hosting seems like a no brainer in retrospect. Since version control already means pushing files to a remote server, why not use that same system to deploy the whole site to a remote server?

Faster, simpler, semi-automated deploys means I get to focus on the fun stuff like designing, writing and coding.

1. My blog is actually built on Jekyll, which is what Github pages is built on. If I didn't have custom Ruby plugins, Github would magically parse my repo.
2. Not familiar with your bash alias? It's basically a file that allows you to save terminal commands to shorthand aliases.