Umi Uyuraのブログ

プログラミング関連の作業ログ

GitHub Pagesでプロジェクトページを作ってみた

先日、React + Material UIでタイムゾーン変換ツール TimezoneConv を作ってみました。

umi-uyura.hatenablog.com

公開するにあたって、当初はHerokuもしくは別のホスティングサービスを使おうとも思ったのですが、Reactとは言えサーバーサイドレンダリングを使っているわけでもなく、ソースをGitHubで管理していることもあり、GitHub Pagesを使ってみることにしました。

GitHub Pagesとは

GitHub Pages

必要なファイル一式をGitHub上のリポジトリにアップすることで、静的サイトとして公開できるというサービスです。

GitHub Pagesの使い方としては、大きく2つあるようです。

種類 割り当てられるURL
ユーザー or Organization用サイト http://<ユーザー名 or Organization名>.github.io/
プロジェクト用サイト http://<ユーザー名 or Organization名>.github.io/<プロジェクト名>/

Organizationの例としては、Homebrewのサイトなどがあります。

URLは http://brew.sh ですが、サイトのソースは Homebrew/homebrew.github.io で管理されています。

プロジェクト用サイトの例としては、Material UIのサイトがそうでした。

こちらもURLは http://material-ui.com になっていますが、その実体は http://callemall.github.io/material-ui/ というGitHub Pagesです。

GitHub Pagesでは、独自ドメインも適用することができるんですね。

GitHub Pages用のブランチを作る

ユーザー用の場合、 \<ユーザー名 or Organization名>.github.io というリポジトリを作成することで、サイトが生成されるようです。

プロジェクト用の場合は、該当するプロジェクトのリポジトリ内に gh-pages というブランチを作成して、サイトに必要なファイル類をコミットすることで、サイトが生成されます。

そのとき、普通に $ git checkout gh-pages などとしてブランチを作ってしまうと、それまでのプロジェクトへのコミットを引き継いでしまうため、サイト自体には不要な履歴が残ってしまうことになります。

そこで調べてみたところ、以下のコマンドで、それまでの履歴とは切り離したブランチを作ることができることがわかりました。

$ git checkout --orphan gh-pages

参考: gitのブランチについてのまとめ

あくまで履歴が切り離されているだけで元のファイル類は残っているので、Minifyした公開用のファイルを生成後、それ以外のファイルを削除してから、あらためて gh-pages ブランチにコミットします。

その後、 gh-pages ブランチをGitHubpush することで、プロジェクトページが生成されました。

今後の課題

調べている途中でこんなエントリを発見。

github-pages - Github pages に 特定のディレクトリだけデプロイする - Qiita

現状は、公開用のファイル一式をプロジェクト直下に作った public フォルダに出力するようにしているのですが、これだと gh-pages ブランチに切り替えた後、その public 内のファイルをルートに移動する手間があります。

バッチスクリプトを用意するのも良いのですが、Browserifyを噛ませていたり、公開用にMinifyしたりと、開発用と公開用で複数のアウトプットが発生することもあり、もう少しプロジェクトの構造も整理して、公開時の手間を減らせるようにしたいところ。