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
のしやすさが重要になるということだ。