gh-pagesブランチの管理にはいくつか手法はあると思うのだけど、決定版はなさそうに思える。まともにやるとするとsubtreeを使うのが良さそうだが、パワフルすぎて役不足な印象だ。僕は公開するファイル群を吐くサブディレクトリーをmasterからは無視しつつ、gh-pagesブランチではそのサブディレクトリーをルートにするみたいな運用に落ち着きつつある。

example.com/
├ dist/
│ └ index.html
├ src/
│ └ index.mustache
├ .gitignore
├ index.js
└ package.json

Node.jsでindex.jsを使ってsrc/index.mustacheを処理し、dist/index.htmlを吐くという形だ。ルートでは.gitignoredist/を無視し、普通にoriginを追加しておく。dist/で改めてgit initし、ルートと同じoriginを追加しつつブランチはgh-pagesに向くようにしておく。

サブディレクトリーではファイルの更新と追加、削除しか起こらないので、機械的に以下のようなコマンドを発行するのみでGitHub Pagesが更新できる。

$ cd dist/ && git add --all && git commit -m "Build" && git push origin gh-pages

このあたりがメリットと考えて使っている。

デメリットとしてはgh-pagesブランチをまとめてpushすることがGitからはできないので、npmスクリプトなどでまとめてpushする手法を編み出す必要があることが挙げられる。他にも2回cloneしないと他のPCに作業環境を作れないことあたりもなかなか厳しそうだ。

ここに至って通常はsubtreeに落ち着く理由がようやくわかった。つまり複数の人間が触る環境だと、何よりもcloneのしやすさが重要になるということだ。