I blogged before on this, but there were some snafus with the usability of the site. I wanted to test the new online editing of resources, that would be crucial to end-user adoption of GitHub Pages (GHP henceforth) as a CMS solution, and couldn’t. Working with GitHub tech-support (Yossef Mendelssohn), it was determined that I’d setup the GHP repositories incorrectly, and should try again with a more regular design.

So I’ve started over.

Incidentally, this stuff (GHP as a CMS) is ready for prime-time now. Have a mostly static-content corporate website? Move it to GHP :)

Steps

1. I’ve tinkered with my DNS to have rabbieburns.paulhammant.com
2. I made a new repo https://github.com/paul-hammant/rabbieburns. I didn’t create a master branch or push anything up to it.
3. I went to the admin for that site, and action the wizard to setup GHP. Settings -> Automatic Page Generator
4. I cloned the repository down to my Mac.
5. I deleted the generated GHP files (I want a different look/feel to the ones offered)
6. I copied over my pre-existing Jekyll site for Robbert Burns content without retaining SCM history from where I had it before.
7. I added a CNAME file with a single line “rabbieburns.paulhammant.com”, and pushed all that back.

At this stage, the site deployed and was navigable online : http://rabbieburns.paulhammant.com

1. I made a second DNS entry for staging.rabbieburns.paulhammant.com
2. In github’s web interface, I forked the repo into https://github.com/paul-hammant-fork/rabbieburns
3. In that repo’s admin interface, I renamed it to ‘rabbieburns-staging’ making the lasting URL for it https://github.com/paul-hammant-fork/rabbieburns-staging
4. I cloned that to my Mac, changed the CNAME record to “staging.rabbieburns.paulhammant.com” committed, and pushed that back.

The second site is now working : http://staging.rabbieburns.paulhammant.com

Making changes through the web interface for ‘staging’ using workflow to get them to ‘production’

1. I changed a file in the web interface: https://github.com/paul-hammant-fork/rabbieburns-staging/commit/3a1e~eda1
2. I added another: https://github.com/paul-hammant-fork/rabbieburns-staging/commit/234f~8117

Both of these automatically redeployed the site as they were completed through the GHP web interface

In the GitHub admin app for paul-hammant-fork/rabbieburns-staging, I clicked “Pull Request”, and made one comprising those two, and one more that I’d made in a local clone (as a developer would): https://github.com/paul-hammant/rabbieburns/pull/1. I’m going to leave that hanging there, but were I to accept it via the web-interface (subject to permissions), it would merge into the ‘production’ repo and redeploy the site.

This is as non-programmers would use the CMS. Clearly roles/permissions would need to be created for a team. Specifically, not everyone should be able to merge changes from staging to production. You’re also still going to need a hardcore Git expert on hand for tricky stuff (more later).

A clone of both repos into two branches of one repo

Maybe only one person in the team using this for formal CMS needs to a Git expert. There are going to use this facility for tricky stuff, and end-users are going to occasionally turn to them for help (rolling back a change, etc).

Setup like so:

clone ‘production’ to a local machine, as usual

git clone git@github.com:paul-hammant/rabbieburns.git

#_ rename branch to ‘production’

git branch -m gh-pages production

#_ rename the remote to ‘production’

git remote rename origin production

#_ add staging as a second remote for ‘staging’

git remote add staging git@github.com:paul-hammant-fork/rabbieburns-staging.git

#_ bring down the files for that

git fetch staging gh-pages:staging

You can now flip branches quite easily:

git checkout staging
more CNAME
git checkout production
more CNAME

Note: Calling a remote AND a branch the same name, is perhaps foolish.

Making sure that CNAME change never gets merged back to the ‘main’ (production) site

git checkout production
git merge --strategy=ours staging
git push production production:gh-pages

This is to maintain divergence between the two sites for the single aspect of the domain name.

Here’s that commit: https://github.com/paul-hammant/rabbieburns/commit/90bd~918c

Note there’s no content.

Using ‘–raw’ we can see WTF the commit was all about:

ph7785:rabbieburns paul$ git show --raw 90bd00be138253dce560422394a2caf7c11e918c

commit 90bd00be138253dce560422394a2caf7c11e918c
Merge: 1044f3f 2729bb8
Author: Paul Hammant <paul@hammant.org>
Date:   Tue Jan 1 18:09:25 2013 -0600

    non-merge of CNAME, to prevent it being offered as a merge again

Note that the pull request mentioned in “Making changes through the web interface….” above, does not contain the change to CNAME, which is exactly what we want.

A Remaining Snafu

Note that I have one repo under ‘paul-hammant’, and the other under ‘paul-hammant-fork’ ?

GitHub won’t allow you to fork an item you already have a fork (or the canonical version) of. It is a rule. I wish they’d push past it, to enable much more corporate use of GHP in the style I outline.