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