Github Pagesは Github の無料静的ウェブページホスティングサービスです。個人ブログ、プロジェクトの紹介 / ドキュメント、組織の公式ウェブサイト（例えば研究室の公式サイト）などに使用できます。本記事では Github Pages の使用方法を詳しく説明します（実際の手順は非常に簡単で、最短 10 分でウェブサイトを立ち上げることができます）。始める前に簡単な紹介をしますが、プロジェクトホームページや個人ブログの具体的な手順に直接飛んでも構いません。
Pages の紹介#
Pages の利点は、サーバーやデータベースなどの環境を用意する必要がなく、シンプルで、安定していて、無料であることです。これにより、Pages は個人ブログ、プロジェクトホームページ、企業の公式サイトなど、純粋に表示目的のサイト（収益を生まない可能性もあります 😂）に非常に適しています。欠点は、静的ウェブページのみをホスティングできることで、つまり、各訪問者に表示される内容は同じです。しかし、Pages 内に動的要素を持たないわけではなく、Issue や Discussion を組み合わせてブログコメントを実現することも可能です。ただし、ログイン機能を持つような複雑なウェブサイトや、複雑なデータ処理が必要な場合は、サーバーのバックエンドがあった方が便利です。
Pages はプロジェクトが更新されるたびに 2 つのことを行います：
- プロジェクト内の Markdown を Jekyll を使ってウェブサイトに変換します
- このウェブサイトをホスティングします
Jekyll は設定ファイルに基づいて Markdown ファイルを処理するため、すべてのウェブページはそのまま保持されます。そのため、構築済みのウェブサイトをプロジェクトに直接プッシュすることも可能で、ホスティングを無料で利用することができます。この方法は、hexoやhugoなど、どのような方法でも使用できます。プロセスは、Jekyll をローカルで構築してからウェブサイトを直接アップロードするのと同じです。
要約すると、Pages を使用する主な方法は 3 つあります。
- Markdown をアップロードし、Pages に Jekyll を使ってウェブサイトを構築させる
- Markdown をアップロードし、Github Action を使ってウェブサイトを構築させる
- ウェブページを直接アップロードし、Pages にホスティングさせる
これら 3 つの方法は、操作の複雑さと柔軟性が順次増加します。
- 最初の方法は最も簡単で便利ですが、Pages の Jekyll は13 個のプロジェクトホームページ用にデザインされた単一ページテーマしか提供していないため、通常はプロジェクトホームページにのみこの方法を使用します。
- 個人ブログや組織の公式サイトは、2 番目の方法を使用することが多く、テーマプロジェクトを直接フォークするだけで済み、柔軟性があり、ローカル環境を設定する必要もありません。Action の構築スクリプトは通常 Jekyll テーマに付属しているため、自分で書く必要はありません。
- ウェブページを直接アップロードする方法は最も柔軟性が高いですが、大多数のシーンでは必要ないと感じます。Jekyll のようなツールを使用せずに自分でウェブページを書いた場合を除いて、2 番目の方法で十分だと思います。
Github#
このセクションは、Github や git バージョン管理ツールを全く使ったことがない読者向けに、Github の登録方法、プロジェクトの作成方法、git とは何かを簡単に説明します。
Github はコードホスティングプラットフォームで、開発者はこのプラットフォームにコードをアップロードし、プロジェクトの複数の開発者がコードを同期しやすくします。また、オープンソースプロジェクトの普及にも役立ちます。登録にはメールアドレスが必要で、Github 登録ページにアクセスし、指示に従って操作すれば大丈夫です。
Github 上のプロジェクトは自分で新規作成することも、他の人のプロジェクトをコピーすることもできます。ブログを作成する場合、テーマプロジェクトを直接コピーすることが多いです。Fork とは、他の人のプロジェクトをコピーして自分の Github アカウントに保存することを意味します。各プロジェクトの右上には Fork ボタンがあります。
クリックすると、自分の新しいプロジェクトにリダイレクトされ、プロジェクトの内容と名前は元のプロジェクトと同じです。このプロジェクトは自分のアカウントにあり、変更が可能です。
自分のプロジェクトを作成する場合は、ホームページの左側にある緑色の新しいプロジェクトを作成（New）ボタンをクリックすれば大丈夫です。
一般的には README.md を追加することをお勧めします。空のプロジェクトは Github から直接プルすることができず、ローカルでいくつかの操作を実行する必要があり、少し面倒です。
git はコードバージョン管理ツールで、簡単に言うと、コードを書く過程でいくつかのアーカイブポイントを作成できるツールです。開発者が 1 人だけの場合、これらのアーカイブポイントはおそらく直線的で、新しいものが古いものの上に重なります。複数の開発者が同時にプロジェクトを変更する場合、アーカイブポイントは平行なパスを持つことができます。個人ブログを作成する場合、git の知識を多く理解する必要はなく、コマンドラインを使用する必要もありません。例えば、Github Desktopやgitgなど、インターフェースを持つ多くの git ソフトウェアがあります。ブログを作成する最も簡単な方法は、テーマプロジェクトをフォークし、プロジェクトをローカルにプルして変更を加え、その後変更を Github にプッシュすることです。後で具体的な操作について説明します。
プロジェクトホームページ#
最も簡単なところから始めましょう。プロジェクトホームページ、つまり Pages を使用して Markdown をどのようにアクセス可能なウェブサイトに変換するかを紹介します。まず、Github プロジェクトを開き、Settings->Pages ページに進みます。Pages が有効になっていないプロジェクトはこのようになります。
Source で Markdown があるブランチを選択します。
次のフォルダオプションは、このブランチ内で Markdown ファイルを探す場所を指定します。ルートディレクトリに README.md が 1 つだけある場合は、デフォルトの /(root) のままで大丈夫です。ドキュメントが複数のファイルに分かれている場合は、すべて docs フォルダに置き、/docs を選択します。
保存します。
少し待つと、上記の URL にアクセスするとウェブページが表示されます。Pages は環境を使用して静的ウェブサイトを生成し、ホスティングします。進捗を確認する方法は、まずプロジェクトのホームページに戻ります。
右下に Enviroments が表示され、github-pages をクリックします。
デプロイの実行状況を確認でき、数回リフレッシュすると新しいデプロイ記録が表示されます。view deployment をクリックするとウェブページにリダイレクトされます。
デフォルトのデプロイにはテーマがないため、見た目が少し素っ気ないかもしれません。Settings -> Pages -> Theme Chooser -> Choose a theme でテーマを選択できます。
クリックするとテーマのプレビューが表示され、Select Theme をクリックしてテーマを選択します。
この時、Pages はコード内に_config.yml ファイルを作成し、選択したテーマを記録します。内容はこのようになります。
少し待つと、Pages が更新され、テーマ付きのウェブページが表示されます。
Pages は 13 個のテーマを提供しており、プロジェクトホームページにはこれらの 13 個以外のテーマを使用することはお勧めしません。Pages のドキュメントには外部テーマの使用方法が記載されていますが、Pages の Jekyll 環境は比較的シンプルで、多くのテーマは gem 依存関係を欠いており、デプロイプロセスには詳細なログがないようです。問題が発生した場合、ほとんどの場合、以下のように「構築失敗」とだけ表示され、デバッグが難しいです。
サードパーティのテーマを使用したい場合は、Action を使用して環境を作成し、コンパイルすることをお勧めします。
個人ブログ#
次に、この記事の本題に入ります。Pages を使用して個人ブログをデプロイする方法です。プロセスは非常に簡単で、テーマを選択し、Jekyll や類似のツール（例えばhexo、Octpress）を使用して Markdown を HTML に構築し、その後 Github プロジェクトにプッシュするだけで完了します（私は個人的に Jekyll しか使用していないため、以下の説明も Jekyll に基づいていますが、他のツールでもプロセスは同様です）。この構築のステップは通常 Github Action を使用し、非常に便利で、構築プロセスは 10 分で完了します。ローカルでの構築は少し面倒ですが、柔軟性が高いので、以下でそれぞれ紹介します。
テーマ#
もしフロントエンドの達人であれば、HTML、CSS、JS、Liquid などの言語を使って自分でテーマを作成することもできますが、Jekyll には非常に豊富なテーマエコシステムがあり、すぐにフォークして使用できます。テーマを選ぶ際の指針は、見た目と使いやすさです。見た目は個人の美的感覚によるもので、特に言うことはありません。使いやすさは、テーマの機能ができるだけ豊富であることを望みます。一般的な機能には以下が含まれます：
- ブログ内検索
- 自動生成されたサイトマップ：検索エンジンのインデックスに便利で、検索エンジンはブログの主要なトラフィック源になる可能性があります
- 記事のタグとカテゴリ：ブログのホームページは通常、発表順に記事を表示しますが、内容が増えるとタグとカテゴリが非常に便利になります
- 記事目次 TOC：長文に役立ちます
- 公開時間、修正時間：公開時間は通常ありますが、修正時間は git の記録を確認する必要があり、すべてのテーマにあるわけではありません
- ダークモード
- コードブロック
- 数式
- ...
これらの機能はテーマに含まれていなくても自分で追加できますが、テーマに含まれている場合は多くの手間を省くことができます。テーマは通常 Github プロジェクトであり、質の高いものは通常 Star や Fork の数が多く、更新頻度も高いです。良いテーマは通常、詳細なチュートリアルがあり、デプロイプロセスでも問題が発生しにくいです。
この記事では、私が現在使用しているChirpyを例に挙げます。その他のテーマについては、以下のサイトをチェックしてみてください。
テーマをフォークすることをお勧めします。利点は、Github が最近出した Fetch Upstream を使って上流のテーマを更新するのが便利なことです。
プロジェクトをフォークした後は、ユーザー名.github.io 形式にプロジェクト名を変更する必要があります。例えば、私の Github ユーザー名が linhandev の場合、プロジェクト名は linhandev.github.io になります。Settings の最初の設定がそれです。
名前が衝突する場合は、以前のブログを削除する必要がありますが、必ず内容を保存してください。以前、書いた記事を何度も失ったことがあります。。。名前を占有しているプロジェクトは削除する必要はなく、名前を変更すれば大丈夫です。
テーマの README を確認し、使用方法についての説明を見てみましょう。一般的には、フォーク後に必要な操作が詳しく書かれています。例えば、Chirpy ではスクリプトを実行する必要があります。ドキュメントを読むのは退屈ですが、問題が発生した後にデバッグするよりも時間を節約できます。計画を立ててから行動することが重要です。最近の面接で、自分のこの点がかなり不足していると感じました。
Jekyll の主要な設定は、ルートディレクトリの_config.yml ファイルにあります。例えば、ウェブサイトのタイトル title、副タイトル tagline、タイムゾーン timezone、アバター avatar、いくつかのソーシャルメディア設定などです。このファイルを確認し、一般的には各設定が何であるかのコメントが付いているので、変更したい部分を変更します。
Action 構築#
Action を書くのは少し複雑ですが、ほとんどのテーマは Action 構築のスクリプトを自動的に持っているか、Pages の環境を直接使用できます。この部分を書く目的は、ブログの構築が失敗したときにデバッグを容易にするためです。将来的には、この Action の具体的な書き方を更新するかもしれません。テーマがこのスクリプトを提供していない場合、自分で Action に不慣れであれば、ローカル構築の方が簡単です。
Github Action は、プロジェクトにいくつかのアクションがあった後にトリガーされます。例えば、push や Issue の作成などです。Action の設定はプロジェクトの.github/workflows フォルダ内にあります。まず、テーマの README.md にある使用開始に関する部分を必ず確認してください。いくつかのテーマには初期化スクリプトがあり、以前 Chirpy を使用していたときにドキュメントを注意深く見なかったために多くの無駄な道を歩んでしまいました。
毎回 push 更新後、Action は自動的に実行され、プロジェクトのコードページの commit の左側にアイコンが表示されます。これは下の赤枠の位置です。
Action の実行中は黄色の点が表示され、実行成功時には緑のチェックマークが表示されます。赤いバツが表示される場合は、実行に問題が発生したことを意味します。実行が成功した後、コードの左上にあるドロップダウンメニューをクリックして、ブランチが追加されているか確認します。
Settings->Pages の設定を変更し、Source をこのブランチに変更します。
commit の左側のグラフが赤いバツの場合、Action の実行ログを確認して具体的な問題を特定できます。
- プロジェクト上部の Action をクリックすると、すべての実行が表示されます。
- その中の 1 つの実行をクリックすると、以下のようになります。
- continus-delivery の位置にあるボタン（必ずしも同じ名前ではない）をクリックすると、具体的な実行ログが表示されます。
エラーの部分を展開すると、具体的な問題がわかります。
最初の Action 実行には環境を作成する必要があり、依存関係のインストールが遅くなることがあります。数分かかることがあります。Chirpy の Action スクリプトは Ruby の環境をキャッシュするため、以降の実行はおそらく 30 秒程度で済みます。Action が成功した後、Pages は数分後に更新されるため、Action が成功すればこのリリースには問題がありません。待つだけで大丈夫です。
ローカル構築#
Action を使用して構築するのは非常に便利ですが、主な欠点は、毎回 push 後に数分待たなければならないことです。通常は問題ありませんが、何度もコンパイルしてデバッグする必要がある場合は、待たされるのが面倒になることもあります。ローカルで Jekyll を実行すると、リアルタイムでコンパイルされ、Markdown ファイルを保存した後にウェブページをリフレッシュすると更新が表示されます。
環境のインストール#
Jekyll は Ruby で書かれており、ローカルで実行するには Ruby と Ruby のパッケージ管理ツール RubyGem をインストールする必要があります。ここでは Arch Linux のインストール手順を示します。他のシステムについては公式のインストールドキュメントを参照してください。
sudo pacman -S Ruby base-devel
インストール中に小さな問題が発生しました。pacman で清華源のいくつかのファイルが常に失敗しました。解決策は、清華源のウェブサイトにアクセスし、対応するインストールパッケージファイルを直接ダウンロードして pacman -U でインストールすることです。Ruby をインストールした後、ソースを変更し、次に jekyll と bundle をインストールします。
# 清華源を追加し、デフォルトのソースを削除
gem sources --add https://mirrors.tuna.tsinghua.edu.cn/Rubygems/ --remove https://Rubygems.org/
gem sources -l # すべてのソースをリスト表示、TUNAだけのはず
gem install jekyll bundler # パッケージをインストール
bundle # bundleでjekyllの依存関係をインストール
jekyll # インストールが正しいかテスト
# 最初の2行の出力は以下のようになります
# A subcommand is required.
# jekyll 4.2.1 -- Jekyll is a blog-aware, static site generator in Ruby
上記の最後の行が「jekyll コマンドが見つかりません」と表示された場合、実行可能ファイルのパスに gem の bin フォルダが含まれていない可能性があります。gem installコマンドの出力を注意深く確認し、この問題に関するヒントがあるはずです。bin のパスを PATH に追加すれば大丈夫です。
gem environment # 出力のGEM PATHS部分を確認
export PATH=$PATH:[上記のgem path] # 例えばArchでは/usr/lib/Ruby/gems/3.0.0
jekyll # 修正が正しいか試してみる
# コマンドが見つかれば、この行を~/.bashrcに書き込むと、新しいコマンドラインを開いても有効です
echo 'export $PATH=$PATH:[上記のgem path]' >> ~/.bashrc # 必ず単一引用符、二重引用符は変数の値で置き換えられます
これで Jekyll の環境が設定されました。次に構築とプッシュを行います。
構築とプッシュ#
まず、Github のプロジェクトをローカルにクローンし、新しいプロジェクトを作成するかテーマをフォークします。プロジェクト名は Github ユーザー名.github.io などである必要があります。新しいプロジェクトを作成する場合は、空の Readme を追加すると後でクローンしやすくなります。完了したら、プロジェクトをローカルにクローンします。
git clone https://github.com/[username]/[username].github.io
cd [username].github.io # プロジェクトに移動
新しいプロジェクトの場合、テーマのすべてのファイルをプロジェクトに配置します。_config.yml、index.html、_post などのファイルやフォルダが必要です。
この時点でローカル構築が可能です。
jekyll build # 構築結果は_siteフォルダに保存されます
# または
jekyl b # bは省略形で、効果は同じです
さらに、ローカルサービスを起動してブログを表示することもでき、Markdown ファイルを保存するたびにウェブサイトが自動的に再構築され、ページをリフレッシュすると変更が表示されます。
jekyll serve # その後、Server address: のURLにアクセスすれば表示されます
# または
jekyll s # 省略形
構築が成功したら、構築されたウェブページファイルのために別のブランチを作成します。以下のスクリプトには削除コードが含まれているため、必ず現在のブランチを確認し、誤って Markdown ファイルを削除しないようにしてください。
git branch # 現在のブランチ名を確認
git branch gh-page # gh-pageブランチを作成
git switch gh-page # 新しいブランチに切り替え
git rm -r * # checkoutは元のブランチのすべてのファイルを持ってくるため、それらを削除
git commit -m "clean up"
git push --set-upstream origin gh-page # Githubにプッシュ
git checkout main # 以前のブランチに戻る
ブランチが作成されたら、構築して Github にプッシュします。
# メインブランチで構築
git switch main
jekyll build # mdをhtmlに変換
# _site内に生成されたhtmlウェブサイトをgh-pageブランチのルートディレクトリに配置
git switch gh-page
mv _site .site
rm -rf *
mv .site/* .
rm -rf .site
ls # 404.html、main.htmlなどのファイルがあるはずです
# gh-pageブランチにプッシュ
git add *
git commit -m "Update Blog"
git push
# メインブランチに戻りプッシュ
git switch main
rm -rf _site
git add *
git commit -m "Update Jekyll Blog"
git push
これで複雑な部分はほぼ完了しました。最後に、前と同様に Pages の Source を変更します。Github プロジェクトの Settings->Pages に移動し、Source を gh-page、/root に設定し、保存します。
数分待つと、ウェブサイトにアクセスできるようになるはずです。
ブログコメント#
ブログを読んだ後にフィードバックをもらいたいと思うかもしれません。記事のコメントは静的な機能ではないため、Github Pages だけでは実現できません。私が知っている解決策は主に 2 つのタイプです。
- 自分で構築したり、サードパーティのコメントサービスを使用する
- Github Issue や Discussion に基づくソリューションを使用する
最初はサードパーティのコメントサービスhyvorを使用していましたが、当時は試運営が無料でしたが、現在は有料になりました。このようなサービスのプランは一般的に非常に大きく、例えば hyvor のスタートプランは月額 $5 で 10 万ページビューがあります。私の生涯でブログがそんなに大きなトラフィックを持つことはないでしょう。😂
Github のサービスは依然として良心的です。😂 この種のプロジェクトはたくさんあり、一部のテーマはその中のいくつかに内蔵のサポートを提供しています。例えば、Chirpy は disqus、utterances（Issue ベース）、giscus（Discussion ベース）を内蔵しています。このようなソリューションの主な欠点は、すべてのプロジェクトがユーザーに Github でログインしてもらう必要があることです。一部はユーザーに OAuth の承認を求めることもあります。
現在は utteranc を使用しており、これを例に挙げます。他のものもあまり変わりません。
utteranc は各記事に Issue を作成し、ユーザーのコメントはその Issue の返信として保存されます。コメントする際には、ユーザーが Github アカウントでログインし、その後 utteranc に承認を与える必要があります。
インストールプロセスは非常に簡単です。
- この URLにアクセスし、Github 上で utterances アプリをインストールします。
ブログのプロジェクトにのみ権限を与えることができます。
- インストールが完了すると、utteranc のウェブサイトが開き、ガイドに従って設定を行います。まずプロジェクト名を入力します。
- 各記事の Issue のフォーマットを選択します。
ここで注意が必要なのは、utteranc が設定したフォーマットに基づいて記事に対応する Issue を探すことです。基本的には記事のタイトルや Markdown ファイル名に基づいています。記事のタイトルや md ファイル名を変更した場合、対応する Issue の名前も変更する必要があります。そうしないと、コメントを見つけることができません。個人的には最初の設定が最も良いと思います。ファイル名は記事名よりも変更されることが少ないでしょう。
- 次に、utteranc が Issue を作成するためのラベルを入力できますが、あまり意味はありません。
- 最後に、テーマの視覚に調和する色を選択します。
下に表示されるコードを記事テンプレートの本文の下に挿入すれば使用可能です。Chirpy の文章テンプレートは_layouts/post.htmlにあります。他のテーマも似たような構造です。最終的な効果は以下の通りです。
ローカル編集環境#
Markdown は所見即所得ではなく、画像を挿入するのが一般的に少し面倒です。ローカル環境はこれらの問題をうまく解決し、執筆プロセスを簡素化します。個人的には Atom が非常に好きで、別の記事でAtom の Markdown 執筆設定を記録しましたので、参考にしてください。
検索エンジンのインデックス#
一般的に個人ブログのトラフィックはあまり多くなく、Chirpy テーマの作者は、ブログの閲覧数機能を有効にすることを推奨していません。創作意欲を削ぐのを恐れているからです。😂 しかし、もしあなたのブログに高品質なコンテンツがあれば、検索エンジンはある程度のトラフィックをもたらすことができます。
検索エンジン最適化は一つの学問ですが、非常に気楽に検索エンジンに「私はウェブサイトを持っています。クローリングするかどうかはあなた次第です」と伝えるだけであれば、robots.txt を追加し、その後サイトマップを提出するだけで済みます。
サイトマップはウェブサイトの地図のようなもので、クローラーにこのウェブサイトにはどのページがアクセス可能かを教えます。ほとんどのテーマはこの機能を持っており、[github id].github.io/sitemap.xml にアクセスすると、404 でなければサイトマップが存在することになります。例えば、私のサイトはこのようになっています。
もしあなたのテーマがサイトマップを持っていない場合でも、自分で追加することができます。
robots.txt は、検索エンジンにウェブサイト上のどのページをクローリングすべきか、どのページをクローリングすべきでないかを伝えるためのものです。[github id].github.io/robots.txt にアクセスして、このファイルが存在するか確認できます。存在しない場合は、プロジェクトのルートディレクトリに robots.txt ファイルを追加するだけで済みます。最もシンプルな書き方は以下の通りです。
User-agent: *
Disallow: /norobots/
Sitemap: https://[github id].github.io/sitemap.xml
{: file='robots.txt'}
このファイルは、すべてのタイプのクローラーがこのウェブサイトをクローリングできることを示し、/norobots/ パス以下のすべてのページはクローリングできず、ウェブサイトのサイトマップの場所を示します。
robots.txt とサイトマップが揃ったら、検索エンジンにウェブサイトを提出できます。ここでは、各種検索エンジンのウェブマスターツール、ウェブマスターまたはサーチコンソールを使用します。以下は一般的な検索エンジンのウェブマスターツールのリンクです。
提出のプロセスは似ています：
- アカウントを登録
- ウェブサイトが自分のものであることを証明
- サイトマップを提出
証明のステップには通常、いくつかの方法があります。Pages の場合、最も便利なのはファイルを追加することです。ファイルをダウンロードしてプロジェクトのルートディレクトリに置き、その後変更を Github にプッシュするだけです。このファイルは、構築前の Markdown ディレクトリに置く必要があり、構築後のウェブページディレクトリには置かないようにしてください。そうしないと、再構築時にこのファイルが消えてしまいます。
もう一つの一般的な方法は、ウェブサイトのヘッダーに meta タグを追加することです。この方法の利点は、複数の検索エンジンを追加する場合、プロジェクトのルートディレクトリが整理されることです（これが利点と見なされる場合）。タグの内容は一連のランダムな文字列です。例えば、私の Bing 検索検証タグは以下の通りです。
<meta name="msvalidate.01" content="D657F7EB150CC9886DA47F92C4D34ED6" />
Chirpy テーマでは、ウェブサイトのヘッダー部分は_includes/head.html で定義されています。あなたのテーマのディレクトリ構造が異なる場合は、プロジェクト内で head で始まるファイルを検索してみてください。見つけたら、この行のコードを head.html の head 部分に追加すれば大丈夫です。
認証が完了したら、サイトマップを含むタブを見つけて、サイトマップの URL を入力すれば大功告成です。私のこのウェブサイトに複数の検索エンジンを追加した後の少ないトラフィックを見た限り、Bing の国内版が新しいウェブサイトに最も優しいようです。おそらく、サイトマップを提出してから 3〜4 日後には cn.bing.com からのトラフィックが見られるでしょう。Google からも 1、2 件のトラフィックがありますが、他の国内の検索エンジンはほとんどクローリングすらしないようです。
トラフィック統計#
立場を変えて考えると、他人に統計を取られるのは嫌なので、私もトラフィック統計は行いません。
カスタムドメイン名#
Pages のデフォルトの URL は固定されており、例えば個人ブログはユーザー名.github.io、プロジェクトサイトはユーザー名.github.io/ プロジェクト名です。しかし、Pages はカスタムドメイン名もサポートしています。
カスタムドメイン名を使用するには、まず自分でドメイン名を持っている必要があります。これは、各種クラウドサービスプロバイダーで購入できます。大まかなプロセスは以下の通りです。
これで完了です。価格は多くの要因によって異なります。例えば、ドメイン名の長さ、トップレベルドメイン、購入期間などによって、年間数十ドル程度です。お金をかけたくない場合は、Freenomで無料のドメインを申請することもできます。
ドメイン解析のバックエンドで、このドメインをユーザー名.github.io に CNAME 解析します。その後、プロジェクトの Settings -> Pages で自分のドメイン名を入力します。この時、gh-page ブランチに CNAME ファイルが追加されますので、ローカルでプルしておかないと衝突します。メインブランチのルートディレクトリにもこのファイルを追加します。これで自分のドメイン名でアクセスできるようになります。
以前、カスタムドメイン名から Github が提供する無料ドメイン名に戻す際に少し問題が発生しました。無料ドメイン名を入力すると、常に以前解析した自分のドメインに直接リダイレクトされ、その後ページが Github の 404 を表示しました。このような場合は、ブラウザのキャッシュをクリアすれば解決します。
結論#
これで、Github Pages の基本的な使い方についての説明は完了です。この文章は今後も更新して修正や充実を図ります。使用中に何か問題があれば、下のコメント欄にメッセージを残してください。