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を吐くという形だ。ルートでは.gitignoreでdist/を無視し、普通に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ブランチへ切り替える作業が必要ないdist/サブディレクトリーでルートのnpmスクリプトを使えるgh-pagesブランチに不必要なファイルとログが含まれないこのあたりがメリットと考えて使っている。
デメリットとしてはgh-pagesブランチをまとめてpushすることがGitからはできないので、npmスクリプトなどでまとめてpushする手法を編み出す必要があることが挙げられる。他にも2回cloneしないと他のPCに作業環境を作れないことあたりもなかなか厳しそうだ。
ここに至って通常はsubtreeに落ち着く理由がようやくわかった。つまり複数の人間が触る環境だと、何よりもcloneのしやすさが重要になるということだ。