GitHub入門ガイド｜Git基礎コマンドからGitHub Pagesでのサイト公開まで

GitHub Pagesとは、GitHubのリポジトリに置いたHTML・CSS・JavaScriptを、そのまま https://ユーザー名.github.io/リポジトリ名/ というURLで公開できる無料の静的サイトホスティングです。レンタルサーバーの契約もFTPも要らず、git push した内容が公開サイトへ反映されます。GitHub公式ドキュメントでは、pushしてからサイトに反映されるまで最大10分かかるとされています（GitHub Docs「Creating a GitHub Pages site」）。

ただし「手順どおりにやったのに公開できない」で止まる人が非常に多いのも事実です。詰まる場所はほぼ3つに集中します。①パスワードでは git push できない（認証）、②ブランチ名が main ではなく master になっている、③公開できたのかどうかを判定する手段がない。この記事では、公開までに必要なGitコマンドを最小限に絞ったうえで、この3つを全部つぶし、最後に「公開できたか」をコマンドで判定する4つの合否ラインまで示します。

GitHub Pagesとは｜リポジトリがそのまま公開サーバーになる仕組み

GitHub Pagesは、リポジトリの中身をそのままWebサーバーの公開ディレクトリとして扱うサービスです。「アップロード」という工程が存在せず、リポジトリへの反映＝サイトへの反映になります。つまりGitHub Pagesを使うには、先にGitとGitHubの操作が必要になります。

Git・GitHub・GitHub Pagesの役割の違い

3つは名前が似ていますが、担当する範囲がはっきり分かれています。

GitHub Pagesでできること・できないこと

「問い合わせフォームを動かしたい」「会員機能を付けたい」といった要件が出た時点で、GitHub Pagesの守備範囲を超えます。その場合は動的サイトを置けるサーバーが必要になるので、ポートフォリオサイトを公開するためのレンタルサーバーの選び方を参考に移行先を検討してください。サーバー側で何が動いているのかを整理したい場合はバックエンド開発の基礎も合わせて読むと、静的と動的の境界がはっきりします。

公開前に押さえる3つの前提｜公開範囲・ブランチ名・使用上限

手順に入る前に、知らないと必ず途中で行き止まりになる前提が3つあります。ここを飛ばすと、あとから作業をやり直すことになります。

前提1｜無料プランではプライベートリポジトリから公開できない

GitHub公式は「If the account that owns the repository uses GitHub Free or GitHub Free for organizations, the repository must be public（リポジトリを所有するアカウントがGitHub Freeの場合、そのリポジトリはpublicである必要がある）」と明記しています（GitHub Docs「Creating a GitHub Pages site」）。無料プランでプライベートリポジトリを作ること自体は可能ですが、そこからPagesを公開することはできません。

公開するリポジトリはインターネット上の誰からでも中身が見える状態になります。APIキー・パスワード・個人情報を書いたファイルを含めたままpushしないよう、コミット前に必ず中身を確認してください。

前提2｜最初のブランチ名は環境によって master になる

GitHubは2020年10月1日以降、新規作成するリポジトリの既定ブランチを main に変更しました（GitHub Changelog「The default branch for newly-created repositories is now main」）。一方で、手元のGit本体が git init で作る最初のブランチ名は今も master です。

実際にGit 2.50.1で、システム設定を無視した状態（GIT_CONFIG_NOSYSTEM=1）で git init すると master が作られます。逆に、macOSのCommand Line Tools同梱のgitのようにシステム設定へ init.defaultBranch=main が書かれている環境では main になります。つまりブランチ名は「環境次第」で、決め打ちできません。

これを知らないと、Pagesの設定画面でブランチを選ぶときに main が一覧に出てこず、そこで詰まります。次のどちらかで main に揃えてください。

前提3｜無料だが無条件ではない｜GitHub Pagesの使用上限

GitHub Pagesは無料で使えますが、公式ドキュメントには明確な使用上限と禁止用途が定められています（GitHub Docs「GitHub Pages limits」）。個人の学習やポートフォリオなら実質困りませんが、事前に把握しておくべき内容です。

加えて用途の制限があります。公式は「GitHub Pages is not intended for or allowed to be used as a free web-hosting service to run your online business, e-commerce site, or any other website that is primarily directed at either facilitating commercial transactions or providing commercial software as a service (SaaS)」と述べており、オンラインビジネス・ECサイト・商用SaaSの運用は許可されていません。ポートフォリオやドキュメントは問題ありませんが、「無料で全部できる」と考えるのは誤りです。

認証を先に通す｜GitHubはパスワードでのpushを受け付けない

GitHubは、Gitの操作でアカウントのパスワードを受け付けません。公式ドキュメントに「Password-based authentication for Git has been removed in favor of more secure authentication methods（Gitのパスワード認証は、より安全な認証方式のために廃止された）」と明記されています（GitHub Docs「About authentication to GitHub」）。廃止は2021年8月13日からで、GitHubは事前に「Beginning August 13, 2021, we will no longer accept account passwords when authenticating Git operations on GitHub.com」と告知していました（The GitHub Blog「Token authentication requirements for Git operations」）。

入門記事の手順どおりに進めて最後の git push だけ失敗する原因は、ほぼこれです。ファイルを作る前に、認証方法を1つ決めて通しておいてください。

3つの認証方法から1つ選ぶ

HTTPSで進める場合、公式はPATの直接入力に加えて「Alternatively, you can use a credential helper like Git Credential Manager」と案内しています。Git Credential Managerを入れておくと、毎回トークンを貼り付ける手間がなくなります。

SSHキーを作ってGitHubに登録する

一度設定すれば以後の入力が不要になるため、同じPCを使い続けるならSSHが扱いやすい方法です。

# 1. SSHキーを作る（メールアドレスはGitHubに登録したもの）
ssh-keygen -t ed25519 -C "your_email@example.com"

# 2. 公開鍵を表示する。出力された1行をすべてコピーする
cat ~/.ssh/id_ed25519.pub

# 3. GitHubの Settings → SSH and GPG keys → New SSH key に貼り付けて保存する

# 4. 接続できるか確かめる
ssh -T git@github.com

cat で表示されるのは ssh-ed25519 AAAA…（長い文字列） your_email@example.com という形式の1行です。拡張子 .pub が付いていない方（id_ed25519）は秘密鍵なので、絶対に貼り付けないでください。手順4を実行すると「Hi ユーザー名! You’ve successfully authenticated…」というメッセージが返り、これが出れば認証は通っています。

PATを使う場合に注意すること

• PATは発行画面を閉じると二度と表示されない。控えを取ってから閉じる
• HTTPSでcloneしたリポジトリで、ユーザー名を聞かれたらGitHubのユーザー名、パスワードを聞かれたらPATを入力する
• 有効期限を設定した場合、期限切れの日から突然pushが失敗する。認証エラーが出たらまず期限を疑う
• PATはリポジトリを操作できる鍵そのもの。ソースコードやスクリーンショットに含めない

公開に必要なGitコマンドはこれだけ

Gitのコマンドは数多くありますが、サイトを1つ公開するだけなら覚えるのは8個で足ります。まず一覧で意味を掴み、そのあと「実際に打つ順番」をそのまま実行してください。

最低限のコマンド早見表

実際に打つ順番（この順でなければ失敗する）

コマンドは順番が命です。特に git remote add より前に git push を打つと、必ず fatal: No configured push destination. で止まります（終了コード128）。次のブロックは上から順にそのまま実行できる形になっています。

# 1. 作業フォルダを作ってGitの管理下に置く
mkdir my-site
cd my-site
git init

# 2. ブランチ名を main に揃える（環境によっては master で始まるため）
git branch -M main

# 3. 公開するファイルを置く
echo "<h1>Hello GitHub Pages</h1>" > index.html

# 4. コミット対象にして、履歴を1件確定する
git add .
git commit -m "first commit"

# 5. push先のリポジトリを登録する（GitHubで作ったリポジトリのURL）
git remote add origin git@github.com:ユーザー名/リポジトリ名.git

# 6. push する。5より前に実行すると必ず失敗する
git push -u origin main

HTTPSで認証する場合は、手順5のURLを https://github.com/ユーザー名/リポジトリ名.git に置き換えてください。以降は git add → git commit → git push の3つを繰り返すだけで、変更がサイトへ反映されます。

余裕が出たら覚える補助コマンド

1人でサイトを公開するだけなら不要ですが、履歴を追ったりブランチを分けたりする段階で使うものです。

コマンドを打つのが不安なうちは、エディタのGit連携から操作しても構いません。VS Codeなら差分の確認・ステージング・コミットをGUIで完結できます。導入する拡張機能はVSCodeおすすめ拡張機能にまとめています。

GitHub Pagesのセットアップ方法

認証とブランチ名の準備ができていれば、ここからは5ステップで終わります。

ステップ1｜リポジトリを作る

GitHubの右上のメニューから「New repository」を選び、リポジトリを作成します。前提1のとおり、無料プランでは公開範囲を「Public」にしてください。リポジトリ名の付け方で、あとで決まる公開URLの形が変わります（ステップ4で詳述）。

ステップ2｜index.html を置いてpushする

リポジトリの直下に index.html を置きます。これがトップページになります。前章の「実際に打つ順番」をそのまま実行すれば、この状態が作れます。

ページ数が増えてくると、CSSや画像をどのフォルダに置くかで後々の修正コストが変わります。最初にファイル配置を決めておきたい場合はディレクトリマップの作り方を参考にしてください。公開後にURL構造を変えるとリンク切れの原因になるため、URLとディレクトリ構造の設計も先に目を通しておくと安全です。

ステップ3｜Settings → Pages で公開元を指定する

現行のUIでは、公開元は「Build and deployment」という区画の「Source」ドロップダウンで指定します。手順は次のとおりです（GitHub Docs「Configuring a publishing source for your GitHub Pages site」）。

1. リポジトリ名の下にある「Settings」タブを開く
2. サイドバーの「Code and automation」区画から「Pages」を選ぶ
3. 「Build and deployment」の「Source」で Deploy from a branch を選ぶ
4. branchドロップダウンで公開するブランチを選ぶ（main など）
5. folderドロップダウンで /（リポジトリ直下）か /docs のどちらかを選ぶ
6. 「Save」を押す

「Source」には2つの選択肢があります。違いは次のとおりです。

公開用ファイルをリポジトリ直下に置きたくない場合は、docs フォルダにまとめてfolder側で /docs を選ぶ方法があります。ソースコードと公開物を分けたいときに有効です。

ステップ4｜公開URLを確認する

公開URLは2種類あり、リポジトリ名で決まります。ここを取り違えると、正しく公開できているのにアクセス先が違って404を見ることになります。

ユーザーサイトは前提3のとおり1アカウントにつき1つだけです。作品ごとに公開したい場合はプロジェクトサイトを使います。なお保存した瞬間に見られるわけではなく、公式は「It can take up to 10 minutes for changes to your site to publish after you push the changes to GitHub」としています。反映まで最大10分かかる前提で待ってください。

ステップ5｜カスタムドメインを設定する（オプション）

「Pages」設定のCustom domain欄に独自ドメインを入力し、ドメイン側のDNSレコードをGitHubの指定どおりに設定すると、独自ドメインで公開できます。反映後は「Enforce HTTPS」にチェックを入れて、HTTPS配信を有効にしてください。ただし前提3のとおり、商用サイトの運用は許可されていない点は独自ドメインでも変わりません。

公開できたかを確かめる｜4つの合否ライン

GitHub Pagesは「設定を保存した瞬間」ではなく「ビルドが完了した瞬間」に公開されます。公式ドキュメントでも、pushしてからサイトに反映されるまで最大10分かかるとされています。ここでは、うまくいっていないのか、まだ待つべきなのかを切り分ける4つの合否ラインを示します。

検証1｜ローカルは正しいリモートを向いているか

git remote -v

検証2｜コミットが積まれ、正しいブランチにいるか

git branch --show-current
git log --oneline -n 5
git status -sb

git init が作る最初のブランチ名は、Git本体では今も master です（main になるのはGitHubの新規リポジトリ側、または git config --global init.defaultBranch main を設定した場合）。git branch --show-current が master を返したら、git branch -m main で改名してからpushし直してください。

検証3｜公開URLに実際にアクセスして200が返るか

curl -s -o /dev/null -w "%{http_code}\n" https://ユーザー名.github.io/リポジトリ名/

ユーザーサイトのURLはリポジトリ名の付かない https://ユーザー名.github.io/ である点に注意してください。ここを取り違えたまま404を追いかけるケースが少なくありません。

検証4｜「まだビルド中」と「設定ミス」を見分ける

curl -sI https://ユーザー名.github.io/リポジトリ名/ | grep -i -E "^(HTTP|server|x-github-request-id)"

ここまでで200が返れば公開は完了です。表示が真っ白・CSSだけ当たらない場合は、パスの書き方（プロジェクトサイトはサブディレクトリ配下になるため絶対パス /style.css が外れる）か、ブラウザキャッシュが原因です。原因の切り分けはGitHub・VSCode・ChromeでCSSが反映されない原因と対処法にまとめています。ブラウザ側で実際にどのファイルが読み込まれたかを見たい場合はChrome DevToolsでの検証手順が使えます。

GitHub Pagesの活用例

• ポートフォリオサイト 自分の作品を1つのURLにまとめ、応募先へ提示できる
• プロジェクトのデモページ ライブラリやツールを作ったとき、動くデモとドキュメントを同じリポジトリから公開できる
• ドキュメントサイト Jekyllを使えばMarkdownからサイトを生成できる
• 学習成果の公開 練習で作ったページをそのまま公開し、履歴つきで積み上げられる

公開する中身が決まっていない場合は、HTML/CSSの練習問題やJavaScriptのミニアプリで作った成果物をそのまま置くのが手早い方法です。オフラインでも動くようにしたい場合はPWAの実装まで進められます。

公開したサイトを他の人に見つけてもらいたいなら、GitHubリポジトリをそのままCDNとして配布に使う方法もあります。実例はオリジナルのリセットCSSをGitHubからCDN配信する方法で解説しています。検索経由での露出を伸ばしたい場合は技術ブログを検索に載せるための施策も参考になります。

GitHub Actionsで自動化を始める

GitHub Actionsは、リポジトリ内のイベント（push、pull requestなど）をトリガーに自動処理を実行するCI/CD機能です。テストの自動実行、コードフォーマット、デプロイなどをワークフローとして定義できます。Pagesとの関係でいえば、セットアップのステップ3で「Source」にGitHub Actionsを選ぶと、ビルドが必要なサイトも公開できるようになります。

GitHub Actionsの基本用語

無料プランで使えるActionsの実行時間は2,000分／月です（GitHub Docs「GitHub’s plans」）。静的サイトのビルド程度なら、この枠を使い切ることはまずありません。なお前提3のとおり、Actionsで独自にビルドして公開する場合は「10回／時」のビルド上限は適用されません。

よくある質問

Q. GitHubとGitの違いは何ですか？

Gitは手元のPCで動くバージョン管理システムで、ネットに繋がっていなくても変更履歴を記録できます。GitHubはそのGitリポジトリをクラウドで預かり、共有・レビュー・自動化の機能を足したサービスです。GitHub Pagesは、そのGitHubが提供する機能のひとつという関係になります。

Q. GitHubにパスワードでpushできないのはなぜですか？

GitHubが2021年8月13日にGitのパスワード認証を廃止したためです。公式ドキュメントにも「Password-based authentication for Git has been removed」と明記されています。現在は、personal access token（PAT）、Git Credential Managerのような認証ヘルパー、GitHub CLI、SSHキーのいずれかで認証します。認証エラーの多くは、この切り替えができていないことが原因です。

Q. 公開したのに404になります。どこを見ればよいですか？

まず本文の検証3・検証4を実行して、GitHubの配信網に乗っているかを確かめてください。server: GitHub.com が返るなら、ビルド待ち（最大10分）かファイル配置ミスです。そのうえで、①index.html がリポジトリ直下またはSourceで指定した /docs にあるか、②Sourceで選んだブランチと git branch --show-current の結果が一致しているか、③URLがユーザーサイト形式とプロジェクトサイト形式のどちらなのか、の3点を順に確認します。

Q. git init したら master になりました。main に変えるべきですか？

GitHub側で作ったリポジトリの既定ブランチが main なら、手元も main に揃えたほうが混乱しません。git branch -m main で改名できます。以後の git init をすべて main で始めたい場合は git config --global init.defaultBranch main を設定してください。なお master のままでも、Pagesの公開ブランチに master を指定すれば公開自体は可能です。

Q. 無料プランのGitHubではどこまでできますか？

公式には「unlimited public repositories with a full feature set, and on unlimited private repositories with a limited feature set」とあり、パブリックは全機能、プライベートは機能が制限された状態で無制限に作れます。無料プランに含まれるのは、GitHub Actions 2,000分／月、GitHub Packagesストレージ500MB、パブリックリポジトリでのGitHub Pagesなどです。GitHub Pagesの公開はパブリックリポジトリに限られる点に注意してください。

Q. まず最初に触るべきGitHubの機能はどれですか？

リポジトリの作成、git clone、Pull Requestの3つです。この3つで「置く・持ってくる・変更を提案する」という基本の流れが一周します。GitHub Pagesはそこに「公開する」を足すだけなので、先にこの3つを触っておくと理解が速くなります。

まとめ

GitHub Pagesでの公開は、コマンドを覚える作業というより「前提を先に揃える」作業です。順番を間違えなければ詰まりません。

1. リポジトリはPublicで作る（無料プランはこれが必須）
2. 認証方法を1つ決めて先に通す（パスワードは使えない）
3. ブランチ名を main に揃える（環境によっては master で始まる）
4. git remote add を済ませてから git push する
5. Settings → Pages → Build and deployment でSourceとブランチを指定する
6. 最大10分待ち、検証1〜4で公開できたかを判定する

公開が終わったら、次は「見えているものが意図どおりか」の確認です。CSSが当たらない・古い表示のままといった症状は、GitHub Pages特有のパスの問題かキャッシュのどちらかで説明がつきます。切り分け手順はGitHub・VSCode・ChromeでCSSが反映されない原因と対処法を参照してください。

本記事で参照した一次ソースは以下のとおりです。

• GitHub Docs｜Creating a GitHub Pages site（公開範囲の条件・反映まで最大10分）
• GitHub Docs｜Configuring a publishing source for your GitHub Pages site（Build and deploymentの操作手順）
• GitHub Docs｜GitHub Pages limits（サイズ・帯域・ビルド回数・禁止用途）
• GitHub Docs｜About authentication to GitHub（パスワード認証の廃止）
• The GitHub Blog｜Token authentication requirements for Git operations（2021年8月13日からの適用告知）
• GitHub Changelog｜The default branch for newly-created repositories is now main（2020年10月1日の既定ブランチ変更）
• GitHub Docs｜GitHub’s plans（無料プランの範囲・Actions 2,000分／月）
• Git公式ドキュメント（各コマンドの仕様）