Github Pages

静的サイトジェネレータのコンテンツを無料で公開できる的な各種サービス

静的サイトジェネレータとは?

記事本文だけ書いたファイルを放り込むといい感じのウェブサイト/ブログを生成してくれる的な奴です。私はJekyllとHexoを利用しています。

これの良いところは、手元に記事ファイルが残るので修正や移行が楽だとか、好きなエディタで書きやすいとか、ファイル構成が単純なので改造しやすいとか色々ありますが、レンタルブログサービスに比べると、無料・広告なしで公開できるのが大きなメリットと言えます。

そのために、普通にエックスサーバーとか借りてFTPアップロードしてもいいのですが、ちょっとエンジニアくさいサービスを利用するとちょっといい感じにできます。

エンジニアくさいサービスのメリットは?

ざっと挙げますと、

  • サブドメイン型なので
    • SEO的に強い
    • 自分で覚えやすい
  • アカウント取るのがサーバー取るより楽なことが多い
  • かっこいい

などがあります。

エンジニアくさいサービスって具体的には?

  • Github Pages
  • Heroku
  • Windows Azure

などがあります。

これらは、基本的にはプログラムを公開したりウェブアプリを動かすためのサービスだったりするのですが、普通のウェブサイトを公開するのにも使えます。

Github Pages

この手の用途ではもっとも有名かつ資料も多いです。基本的にはプログラムのソースコードを公開するためのサービスですが、解説用ページを開設する機能があり、それだけでも利用できます。アップロード(デプロイ)方法はGit。一応ブラウザだけで作成も可能。

Github Pagesを利用するメリットとして、まずGitホスティングサービスなので、バージョン管理がしやすいというのがあります。なので、ブログより「ドキュメント」の公開に向きます。

また、サーバにJekyllがインストールされているので、自分で生成しなくてもGitだけで運用できます。ターミナルとかコマンドプロンプトとか最低限しか使いたくないという場合、初期構築はともかくとして、更新はGithubデスクトップアプリだけでも可能です。

あと、GitのHTTPSアクセスが可能なので、SSH公開鍵の生成とかしなくてもなんならなんとかなります。事故るポイントが少ないのは良いことです。

デメリットとして、無料でやろうとするとリモートリポジトリが公開になるので、ソースが全部丸見えというのがありますが、まあ別にどうでもいいと思います。

それより、サブドメイン変えたいとか、複数ブログ運営したいとか思うとちと面倒です。グループページ作ればいいだけなんですが。

Heroku

基本的にはウェブアプリのホスティングサービス(PasS)ですが、ブログ運用もよゆーです。アップロード方法はGit。

なにより素晴らしいのはサブドメイン取得が超楽ということです。無料だと1アカウントあたり5個までの制限こそありますが、取得はこれだけ。

1
heroku create

終わり。いや、これだとランダムなアプリ名が生成されるのでリネームとか要りますが、リネームがあっさりできるのもスゴイ。

Hexoの運用テストの時、作ったり消したりが簡単にできて大変助かりました。

SSH必須だし公式GUIクライアントないし、微妙に敷居高い感もありますが、ある程度の知識さえあれば手間はダントツで少ないです。オススメ。

Windows Azure

最近ホットなアイツ。やはり基本的にはPaaSですが、ウェブサイト公開用のオプションもあります。

最大のメリットとしては、多様なアップロード方法があります。Gitは当然として、FTPやDropboxも利用できます。

ん、Dropbox? と色めき立って、自動同期ができるのか調べてみましたが、結論としては不可能です。Dropboxの指定フォルダにソースを保存したら、ブラウザから手動で同期する必要があります。

機能的には一番優れていると思うのですが、とにかくユーザ登録が超めんどくさい。入力項目は多いし、長いし、クレジットカード要るし、なんかすごい料金請求されそうな文面で怖いし、Gitの認証設定は別にしなきゃいけないし。

とりあえず、無料でブログ公開したいときのサービス構成をまとめますと、

  • サブスクリプション従量課金で作成
    • 無料評価版は30日で終了するので利用しない
  • アイテムを種別WEBサイトで作成

これで大丈夫です。

一応、手続きさえすればDropbox経由でブラウザからデプロイできるので、大した知識は要らんのですが、あまりにも複雑すぎるので個人用途ではお勧めできません。

結論

  • ドキュメントはGithub Pages
  • ブログはHeroku

がいいと思います。

サーバサイドJekyllでシンプルなウェブサイト管理

Github PagesではサーバーサイドJekyllが使える

以下のページに詳しいですが、Github PagesではサーバサイドでJekyllを利用することができます。

Jekyllとは、簡単にいえば本文さえ与えればいい感じのウェブページに整形してくれるヤツです。通常はローカルPCで整形してからアップロードするのですが、Github Pagesではサーバ側で整形してもらうこともできます。

使い方

簡単すぎてちょっと戸惑いましたが、既存のテーマなり、jekyll new なんとかかんとかで生成される雛形なりに、原稿ファイルを加えてGithub Pages用のリモートリポジトリ(の適切なブランチ)に送るだけです。もちろん自分で雛形を書いてもいいです。

サーバサイドJekyllにはどんなメリットがあるのか?

自分でビルドする手間が省ける

当たり前ですがこれが第一。

Jekyllは通常ターミナル(Windowsならコマンドプロンプト)からしか実行できないので、自分でJekyllしなくていいということは、ターミナルを使う必要がなくなるということでもあります。

Githubにシンクするだけなら、Github Pagesのデスクトップアプリとかでもできるので。

「完成品」を管理する必要がない

以前も書きましたが、サーバサイドJekyllを利用する場合、手元(リモートリポジトリも含む)には、実際にウェブページとして公開されるHTMLファイルは残りません。

Jekyllで生成されるHTMLファイルは、それ自体を編集したりするものではないので、雛形を組み終わってしまえば扱う必要はありません。うっかり書き換えたり削除したりしないよう神経を使うこともなく、やってしまえば非常に楽です。

シンプルなウェブサイト管理

当初はびっくりしましたが、原稿と雛形だけ管理すればいいというのは気に入りました。

ただし、サーバサイドJekyllを利用する場合、Jekyllのプラグインが利用できません。気になるプラグインもあるので、そのうちローカル生成に切り替えるかもしれません。

Github PagesをサーバーサイドJekyllに切り替えました

表題の通り。

いくつか未解決の問題があるのですが、とりあえずやってみました。

未解決問題

  • White PaperテーマでのTOCへのCSS指定
    • ul#markdown-tocじゃあかんのかい
  • layout:post限定でのヘッダー項目挿入
    • layout基準でのifの書き方がわからん
    • まあindex.htmlにヘッダーいらないからpost.html自体に書いてもいいんだけどさ……
  • pagenationが1ページに収まらないとき限定のprevious/next表示
    • なんで最初からこうなってないんだろ

Github PagesにおけるサーバサイドJekyllの注意点

修正あり

最初、サーバサイドJekyllで_postsフォルダが使えないと勘違いしていた。

Jekyllの基本

Jekyllとは、簡単に静的ウェブサイト(HTMLファイル)を生成することができるソフトウェアである。「本文」と「レイアウト」を組み合わせることで、本文を記述した原稿ファイルに対して、自動的にウェブサイトとしての体裁を整えることができる。

基本的にはPCにインストールして、ターミナル(Winだとコマンドプロンプト)から利用する。

Github PagesではサーバーにJekyllがインストールされており、Jekyllで自動生成を行うために必要なファイル群が揃っていれば、ファイルを送信した時にJekyllによる変換をかけてくれる。

Github Pages特有の条件

設定の上書き

Github Pagesは、_config.ymlの一部情報を上書きする。

上記ページより、上書きされる項目・内容は以下の通り。

safe: true
lsi: false
source: your top-level directory

source指定が不可能であることにより、全てのソースファイルをトップレベルディレクトリに配置しなければならない

Keep in mind that if you change the source setting, your pages may not build correctly. GitHub Pages only considers source files in the top-level directory of a repository.

ただしこれは、Jekyllを実行する基準がリモートリポジトリのトップレベルディレクトリだということであって、各記事の「本文」となるMarkdownまたはTextileファイル(原稿ファイル)をルートフォルダに置かねばならないという意味ではない。

そもそも、Jekyllにおいて、通常原稿ファイルを配置すべきは_postsフォルダだし、そうしたファイル構造は当然Github PagesのサーバーサイドJekyllでも有効である。

また、Jekyllは、ソースフォルダのサブフォルダを再帰的に参照する。(ただし無視するフォルダもある。_draftsとか)
すなわち、ファイル自体が条件を満たしていれば、「原稿ファイル」がどんな深い階層にあろうとも、必ず見つけ出して変換してくれる。

言い換えれば、gh-pagesブランチに置かれたファイルは全部ウェブサイトとして公開されますよということであって、Github Pages専用のリポジトリではあまり関係のないことだ。

それよりも、safe: trueにより、任意にプラグインを追加できないことが、実際的な問題としてあるだろう。

Github PagesにおけるJekyllの駆動タイミング

単純に、ソースファイルをGithub Pages用リポジトリに送信したタイミングで駆動するようだ。

ファイルを配置した後、改めてJekyllを走らせるために何かする必要はないし、逆に言えば、任意のタイミングで走らせることはできない。

変換されたファイルはリポジトリに表示されない

ビックリカンカンである。このことに触れているウェブ上の記事を全く見つけられなかったが、事実のようだ。

例えば、フロントマターでpermalink:example.htmlと指定したとする。

この場合、(ベースURL)/example.htmlで生成されたコンテンツにアクセスできるわけだが、example.htmlというファイル自体は存在しない。というか、ブラウザアクセスできる以上は存在しているわけだが、リモートリポジトリ上には表示されないため、ユーザーが取り扱うことはできない。

また、permalink:blog/example.htmlとした場合、URLは(ベースURL)/blog/example.htmlとなるわけだが、同様にblogというフォルダも、ユーザーが取り扱える範囲内には存在しない。

WindowsでGithub Pages検証用リポジトリ作った時のメモ

リモートリポジトリ作成

Githubウェブサイトでログインして、右上の+から「New Repository」選択して必要事項入力

スクリーンショット

リポジトリページが作成された。(catfist/SandBox

ローカルにクローン

作成したリポジトリページの右メニューから「Clone in Desktop」

スクリーンショット

クローン先に、Github用に使っているフォルダを指定すると、そこにローカルリポジトリが作成された。

スクリーンショット

ここにファイルを追加すれば、Github for Windowsからコミットすることができる。

gh-pagesブランチを作成する

今回はユーザーページではなくプロジェクトページなので、gh-pagesブランチを作成する必要がある。

Github for Windowsで作成する場合、

SandBoxリポジトリを選択した状態で、「Master > Manage」をクリック。

スクリーンショット

右の+をクリックして、

スクリーンショット

ブランチ名を「gh-pages」で入力。

スクリーンショット

gh-pagesブランチをクリックすると、こちらがカレント?アクティブ?になった。

スクリーンショット

右の「Publish」をクリックしてサーバーに反映。

スクリーンショット

gh-pagesブランチが作成された。(catfist/SandBox at gh-pages

このブランチにコミットすれば、Github Pagesとして公開される。

Github Pagesが大変なことになってしまいつらたん

これは一夜の悪戦苦闘の記録というか戒めフォーミーである。

余計なこと:Jekyllさんに走ってもらいたかった

  • Jekyllさんに走ってもらいたかったので、色々ファイルを追加する
  • 大元にコミットするの怖いので、ブランチを作成した
  • Jekyll関係のもろもろプッシュしたが、自動生成自体は失敗

そのときふしぎなことがおこった

  • Github PagesでホストしていたCSSがリンクされなくなった
  • この際、MasterブランチにはCSSファイルがなく、追加したブランチにはあった
  • WindowsとMacを取っ替え引っ替えして作業したため、このようなことが起こったと思われる
  • この現象から判断すると、Github Pagesで公開されるのはMasterブランチだけのようだ
  • ってそう書いてあるがな(master

Masterブランチに合流させたいんですけど!?

  • さっぱりわからない。
  • なんかコマンドラインでやらなきゃいけないような気もしたが、焦っていたのでそんなことしたくなかった
  • めんどくさいので追加したブランチを削除した
  • Github Windowsからコミット対象のブランチを選べばよかったような気もする
  • とにかくブランチが単独になったので改めてCSSファイルをコミット
  • CSSファイルのリンクが復旧した

課題

  • Github Pagesでいろいろ実験したいときはどうすればよいのか
    • Masterブランチで実験しないと結果検証ができない
    • 綺麗なバージョンを分枝しておけばよいのではないか
    • 戻し方がよくわからんが、最悪ブランチページからコピペとかもできるし
  • Github使うならブランチ操作を理解しないとなあ
  • サーバサイドJekyllさえなきゃ、誰がお前みたいな面倒なやつ……!
  • ていうかもう本番リポジトリで実験とか二度とやらねえ

Github PagesでJekyllを使ってtitle付きのページを生成したかった

TOC付きのページを簡単に公開したい

なんか最近ずっとこればっかり言ってますが、したいのです。もっともっと簡単にしたいのです。

現在は、Sublime TextのMarkdown Previewパッケージを利用して、TOC付きのHTMLファイルを生成してからGithub Pagesにプッシュしています。

しかし、titleが全然生成されなくてファイル名そのまんまにしかならないので、なんとかしたいと思っていました。

これが、Github Pagesを使うと簡単にできそうなので、やり方を調べてみます。

用語について整理しよう

Githubとは?

ソフトウェア開発などで、バージョン管理を行うためのサービスです。

Githubは、バージョン差分データと、ファイルそのものを保持してくれます。従って、ある種のレンタルサーバーであるとも言えます。

Github Pagesとは?

Githubの機能のひとつで、まさにレンタルサーバーのように、GithubにアップロードしたHTMLファイルにURLを与えてウェブ公開してくれるサービスです。

Jekyllとは?

静的サイトジェネレータと言われるソフトウェアの一種です。

原稿データテンプレートを与えることで、自動的に(静的な)HTMLファイルを生成してくれます。

これ自体は、ドキュメントを変換するエンジンであり、ファイルを公開する機能は持ちません。

Github PagesにおけるJekyllとは?

Jekyllは基本的にはローカルで動かすエンジンですが、Github Pagesはサーバー側でJekyllを動かすことができ、原稿データとテンプレートをアップロードすると自動変換してくれます。

Octopressってやつとどう違う?

Github PagesでBlogやろう的な記事を読むとよく出てくるOctopressですが、これはJekyllを利用する静的サイトジェネレータです。

それらしいウェブサイト(Blog)を構築するためのCSSなどがパッケージ化されており、Jekyllを用いて、簡単に整ったウェブサイトを構築することができます。

なぜJekyllを使うのか?

Jekyllにはより高度なコンテンツ生成のための拡張機能が存在しますが、その中にTOCを生成するものがあります。titleも生成できます。

これは、Github PagesにホストされているJekyllでも利用することができます。今回はこれを利用したい。

ローカルでJekyll走らせてもええんちゃう?

まあそれでもいいのですが、アップロードしただけでJekyllやってくれるならそのほうが楽だし。

私はギーク度が低いので、できるだけ黒い画面を見たくないのです。

どうやってGithub PagesでJekyllを走らせるのか?

Automatic page generator

Githubのリモートリポジトリを見ると、そんなメニューが用意されています。

GithubリモートリポジトリのSettingから

試してみたのですが、これは環境を構築してくれるわけでもたくさんページを作れるわけでもなく、index.htmlを生成する機能です。

実行する際には、入力したMarkdownテキストをサーバサイドJekyllで変換していると思われますが、これだけでずっと記事を生成していくわけにはいきません。

じゃあどうやるの?

結論から言うと、というかすでにそういう書き方をしましたが、原稿データとテンプレートをアップロードするだけでよいようです。

ちゃんとした用語で言い換えると、ローカルリポジトリに原稿となるMarkdownファイルとJekyllテーマファイル群を用意し、コミット&シンクしてリモートリポジトリにプッシュされると、サーバサイドで自動的にJekyllが走って変換してくれるみたいです。

試しに適当なJekyllテーマをダウンロードして、_congig.ymlを編集してプッシュしてみました。使用したテーマはこちらです。

しかし、なんか_congig.ymlの内容がアカンかったようでこんなエラーメールが来ました。

[catfist.github.io] Page build failure

The page build failed with the following error:

You have an error on line 28 of your _config.yml file. For more information, see https://help.github.com/articles/page-build-failed-config-file-error.

If you have any questions please contact us at https://github.com/contact.

該当箇所は以下の部分でした。

google_analytics:(ここにGoogle アナリティクスのアナリティクスID入れてた)

で、IDを削除してシンクしたら同じエラーが出ました。空でもあかんのかい……

ムカついたので関連しそうなところを全部コメントアウトしてシンクしてみました。

がっ……ダメ!

続く次回!

おまけ:ブランチ初めて分けたよ

今回の実験では、大量の新規ファイルをコミットすることになるため、初めて新規ブランチを作成しました。

これでいつでも原状復帰できるはず……ですが、完全に流れで記録もとらずにやったので、元に戻せるのかどうかよく分かりません。次回以降戻し方も書くかもしれません。

Postach.ioのCSSを書き換えた時のメモ

CSS編集したときのメモ。

Postach.ioでデフォルトテーマを適用した状態で、Source Editorからテンプレートを読んでみる。

CSSに関する指定は以下の通り。

<link href="" rel="stylesheet">
<link href="" rel="stylesheet">
<link href="" rel="stylesheet">

3行目がテーマ別の指定であるようだ。

Postach.ioのCSSはレスポンシブデザインであり、ブラウザの幅によって表示が変化する。そのため、以下は全て幅最大=PC向けの表示を前提とする。

現在の表示は以下の通り。(多少ヘッダー・サイドバーに手を加えてある)

通常デザイン

ここで、このページをHTMLとして保存する。上記のCSS指定が、以下のようにHTMLとして展開されている。

<link href="http://postach.io/static/bootstrap/css/bootstrap.min.css" rel="stylesheet">
<link href="http://postach.io/static/bootstrap/css/bootstrap-responsive.min.css" rel="stylesheet">
<link href="http://postach.io/static/themes/default/default.css" rel="stylesheet">

そこで、3行目をコメントアウトしてみる。その場合の表示は以下の通り。

テーマ固有のCSSを削除

ここから読み取れるdefault.cssによる指定は以下の通り。

  • ヘッダーとボディの重なりを解消
  • フォント指定、背景指定
  • プロフィール画像を丸アイコン化
  • タグクラウドの回り込み

したがって、これらの部分に手を加えるためには、default.cssを自作のCSSに置き換えればよい。また、追加指定も行う。

なお、以下のような指定もあったが、影響範囲は不明だった。

<link rel="stylesheet" href="http://postach.io/static/site/css/social-bar.css?v=05022014" />

そこで、default.cssをダウンロードし、保存したHTMLで読み込むようにして修正・懸賞を行う。

default.cssの編集

ここから、CSSを編集していく。

丸アイコン化を解除

プロフィール画像が丸アイコンに対応していないため、指定を変更する。

HTMLの該当箇所は以下の部分。

<img class="avatar" src="http://postachio-images.s3-website-us-east-1.amazonaws.com/b41cb417d61ac3406bf98585f8bc9a69/avatar.jpg" alt="もりやん" />

CSSの該当箇所は以下の部分。

.bio img.avatar {
  position: absolute;
  top: -33px;
  left: 25px;
  width: 66px;
  height: 66px;
  border-radius: 50%;
}

border-radius: 50%;をコメントアウトするか、値を小さくすることで、画像の全体を表示することができる。今回は、10%で指定した。

テーブル

  • ボーダーを表示
  • 背景色の縞模様化
  • テキストを中央寄せ

CSSの該当箇所は以下の部分。

.post .post-content table {
  margin: 0;
  padding: 0;
}

これを、以下の通りに変更。なお、内容はほぼSublime Text Markdown Previewからパクり。

.post .post-content table {
  border-collapse: collapse;
  border: 1px solid #ddd;
  background-color: #fefefe;
}
.post .post-content table tr:nth-child(2n) {
  background-color: #f8f8f8;
}
.post .post-content td, th {
  border: 1px solid #ddd;
  padding: 6px 13px;
  text-align: center;
}

これで、テーブルの表示が以下のように変更された。

テーブル表示例

画像に縁取りを追加

CSSの該当箇所は以下の部分。

.post .post-content img {
  max-width: 100%;
}

これを、以下の通りに変更。

.post .post-content img {
  max-width: 100%;
  box-shadow:0 0 5px 1px rgba(0, 0, 0, 0.2);
  padding:5px;
  border:1px solid #ccc;
  border-radius:5px;
}

以下のページを参考にした。

画像に縁取りが追加され、見やすくなった。

インラインコードを折り返す

code要素が折り返しされずにボックスからはみ出していたため、以下のページを参考にCSSを追加。

追加内容は以下。

.post code {
  overflow: auto;
  white-space: pre-wrap;
  word-wrap: break-word;
}

見出しのフォントサイズを調整

default.cssの該当箇所は以下の部分。

.post h1 {
  font-size: 28px;
  margin-top: 15px;
  font-weight: 300;
}
.post h2 {
  font-size: 24px;
  line-height: 34px;
}
.post h3 {
  font-size: 20px;
  line-height: 30px;
}
.post h4 {
  font-size: 16px;
  line-height: 26px;
}
.post h5 {
  font-size: 12px;
  line-height: 22px;
}
.post h6 {
  font-size: 8px;
  line-height: 18px;
}

本文の指定は以下の部分。

.post p {
  font-size: 14px;
  line-height: 24px;
}

h5以下の見出しには、本文より小さいフォントサイズが適用されていることが分かる。

なお、本文内の見出しをどのレベルから始めるべきであるかは、実は微妙な問題。

  • トップページで記事全文を表示する場合、記事タイトルがh2なので、本文はh3から始めるべきとなる。
  • 記事個別ページでは、記事タイトルはh1であるため、本文はh2から始めるべきとなる。

この場合、本文は一律にh3から開始するものとする。

今回は、h6を本文と同じ14px指定とし、フォントサイズによって見出しレベルの差を表現する。

また、太字にするとともに、行頭に#を付けることによって、見出しであることを表現する。

よって、以下のように変更する。

.post h1 {
  font-size: 28px;
  margin-top: 15px;
  font-weight: 300;
}
.post h2 {
  font-size: 24px;
  line-height: 34px;
}
.post h3 {
  font-size: 20px;
  line-height: 30px;
}
.post h4 {
  font-size: 18px;
  line-height: 26px;
}
.post h5 {
  font-size: 16px;
  line-height: 25px;
}
.post h6 {
  font-size: 14px;
  line-height: 24px;
}
.post h3,h4,h5,h6 {
  font-weight: bold !important;
}
.post h3:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}
.post h4:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}
.post h5:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}
.post h6:before {
  content: "# ";
  color:#9e9e9e;
  font-weight: bold;
}

下記参考ページのバグが確認されたため、擬似要素のbeforeではセレクタの複数指定を避けている。

編集したCSSをアップロードする

今回は、Github Pagesでホストすることにした。

Github Pagesのローカルリポジトリに編集したdefault.cssを置き、プッシュした。

<link href="" rel="stylesheet">

Source Editorで、上記の部分を以下のように書き換え、ホストしたCSSを参照する。

<link href="http://catfist.github.io/Postachio_default.css" rel="stylesheet">

これにより、編集したCSSが反映された。

ついでに:Postach.ioテーマをBitbucketで管理

Postach.ioのテーマについてもバージョン管理したかったので、Bitbucketに置くことにした。

ただ、当然ファイルとしては存在しないので、わざわざローカルにHTMLファイルとして保存してやる必要があった。

CSSに比べると頻繁にいじるものではないので、そこまでしなくてもいいような気はするが、Dropboxとかに置いておくよりはスマートであるような気もする。

Github Pagesで変換前テキストを公開しないためのIgnore

Github Pagesで変換前テキストを公開しないためのIgnore

変換前後のファイルが同じフォルダに

現在、Sublime TextのMarkdown Previewパッケージで生成したHTMLドキュメントをGithub Pagesで公開しています。

この際、普通にビルドするとHTMLファイルが元のMarkdownファイル(私は.txtにしていますが)と同じフォルダに生成されるので、原稿ごとローカルリポジトリ管理下のフォルダに入れておきたいわけです。

当然、こうすると変換前のファイルまでコミットされてします。そこで、Githubアプリでコミット対象から外します。

コミット対象から外す

  1. ローカルリポジトリ管理下のフォルダに、テキストファイルを保存
  2. Githubアプリを起動すると、テキストファイルの追加が反映されている
  3. 追加されたテキストファイルを右クリックして「Ignore all .txt files」をクリック

これで、全てのテキストファイルがコミット対象から除外されます。よって、元ファイルを修正したら、ビルドしてCommit & Syncするだけで安全に更新できます。

Github Pagesの利点

以下のドキュメントを、Github Pagesで公開しました。

こういった長文をどう生成し、どう公開するのが簡単で楽しいか、色々考えました。

HTMLドキュメントの生成については、「Sublime TextによるTOC生成」にも書いた通り、Sublime Textでの生成が回答になりました。では、公開場所はどうか。

手元にHTMLファイルがある以上、真っ先に考えるのはレンタルサーバーにFTPアップロードです。Sublime TextのSFTPパッケージを使えば、アップロードも一発です。

それに比べ、Github Pagesは開発者でもない身には色々と面倒なことも多いのですが、利点も少なからずあります。

無料、広告なし

基本ですが大事でしょう。単にHTMLを置くだけなので、PHPすら要りませんし。

サブドメイン型

ユーザーページであれば(ユーザー名).github.ioのURLを貰えるので、URLがきれいで気分が良いです。その方がSEO的にも良いらしいですが。

更新履歴が自然に取れる

そもそもがバージョン管理システム(のホスティングサービス)なので、コミット時にコメントを残すことで履歴管理が簡単にできます。

Githubこわくないよ!

そりゃあレンタルブログとかに比べれば知識が要りますが、FTPでウェブサイト管理してた経験のあるオッサンならば大したことないです。結局、ローカルにファイル作って同期するだけですし。

Sublime TextのGitパッケージからPushしようとしたら失敗して、泣きながらGithubアプリ立ち上げたけども…