This blog uses Octopress which is based on Jekyll and apart from it being easy to use, I chose it because it was Ruby and uses git. I figured I might pick something up about Ruby and git when using it.
Even before I had written my first post, Octopress had shown me branches in git that do not have to be related to each other. I will look at using the same technique in a Java library I have, where the same source code is used to produce two versions of a utility. I could have one main branch containing the source code, one for the version 4.7 build and another for the version 5.0 build.
Back to Octopress. If you want to serve up a web site on Github, you need to provide the static files in a
master branch of a repository called
USERNAME.github.io. Octopress showed me how you could have the Jekyll source files in one git branch and the statically generated files in another.
Although many levels deep, the first level of the Octopress directory tree looks like this:
.gitignore file is set to ignore the
public directories. One git repository is initialised in the root, which due to the
.gitignore file means
public are not included in it. Then another repository is initialised in the
_deploy directory. This becomes the
master branch of the
USERNAME.github.io Github repository and contains the website. The other repository becomes the
Using this technique would allow for many seperate source trees to be included in the one Github repository. This should really only be done when the different branches have some direct relationship. In the case of Octopress the
source branch is used to create the
master branch. In my Java library the one branch is used to create the contents of two other branches containing the version specific installation files.
This is a great use of git, but one that should only be used to keep track of related sets of files. More specifically where one branch creates the content stored in the other branch.