GitHubとは?初心者がサイト運用で最初に分けること
Web制作の学習を始めると、必ずと言っていいほど耳にする「GitHub(ギットハブ)」。ただ、初心者が本当に迷いやすいのは、GitHubの機能名よりも「GitHubへpushしたら本番サイトも変わるのか」「秘密情報を入れてよいのか」「AIやCodexにどこまで見せてよいのか」という運用の境目です。
この記事では、GitHub、Git、GitHub Pages、ロリポップなどの本番サーバー、FTPアップロード、clone、pushの役割を分けて整理します。GitHubを単なる用語として覚えるのではなく、サイトを壊さずに履歴を残し、AIへ安全に相談するための作業場所として理解しましょう。
確認日: 2026年5月20日
このページで整理できること
- GitとGitHubの違いを、ローカル作業場と履歴の置き場として分ける。
- GitHub PagesとロリポップなどのPHP本番サーバーを混同しない。
push、clone、pullがサイト運用のどの場面で必要か確認する。- Public / Private、
.gitignore、秘密情報の扱いを先に決める。 - AIやCodexにGitHub運用を相談する時に、貼る情報と伏せる情報を分ける。
そもそも「バージョン管理」って何のこと?
GitHubの話をする前に、まずその根幹にある「バージョン管理」という考え方を理解しましょう。言葉は難しく聞こえますが、実は誰もが経験したことのある、あの悩みを解決するための仕組みです。
例えば、レポートやデザインを作成している時、こんなファイル名がフォルダに溢れかえった経験はありませんか?
design_final.psddesign_final_v2.psddesign_final_本当に最後.psddesign_final_最新版_2.psd
どれが本当に最終版なのか分からなくなり、「やっぱり昨日の状態に戻したい…」と思っても、もう手遅れ。そんな悲劇を防ぐのがバージョン管理です。
バージョン管理システムは、ファイルの変更履歴をすべて記録し、「セーブポイント」を作成してくれます。このセ-ブポイントを「コミット(Commit)」と呼びます。いつでも好きな時点のセーブポイントに戻ったり、過去の変更内容と比較したりできる、まさにコードのタイムマシンなのです。
最大の疑問!GitとGitHubの違いとは?
初心者が最も混乱するのが、この「Git(ギット)」と「GitHub」の違いです。この2つは名前が似ていますが、役割は全く異なります。図で見てみましょう。
あなたのPC(ローカル環境) インターネットの世界(リモート環境)
+-------------------------+ +-----------------------------+
| | | |
| [ Git ] | --- push --> | [ GitHub ] |
| バージョン管理ツール | | Gitの置き場所(サーバー) |
| (セーブポイント作成) | <-- pull --- | (チームで共有) |
| | | |
+-------------------------+ +-----------------------------+
この関係を、身近なもので例えるなら…
- Git: あなたのパソコンに入っている「Microsoft Word」そのものです。文章を書いたり、編集したり、PC内に保存したりするための「道具(ソフトウェア)」です。
- GitHub: 「Google ドライブ」や「Dropbox」のようなものです。Wordで作成した文書ファイルを、インターネット上に保存・共有し、他の人と一緒に編集するための「場所(Webサービス)」です。
つまり、Gitという道具を使ってファイルのバージョン管理を行い、その記録を保存・共有する場所がGitHub、と覚えておけば間違いありません。
最初に分けること
| 場所・機能 | 役割 | 初心者が間違えやすいこと | 次に読むページ |
|---|---|---|---|
| ローカルPC | VSCodeなどで編集し、PHP構文チェックや表示確認をする作業場 | 未確認のまま本番へ上げる | ロリポップPHP保守の入口 |
| GitHub | 変更履歴とバックアップを置く場所 | pushすれば本番サイトも自動更新されると思う | 最初のリポジトリをpushする手順 |
| GitHub Pages | 静的HTML/CSS/JavaScriptを公開できる機能 | PHPやDB接続もそのまま動くと思う | GitHub Pagesで公開する方法 |
| ロリポップなどの本番サーバー | 実際に読者へ表示されるPHPサイトを動かす場所 | GitHubの履歴と本番ファイルの状態を混同する | 公開後に反映されない時の確認入口 |
| AI / Codex | 差分確認、手順整理、修正方針の相談相手 | DBパスワード、FTP情報、管理画面URLをそのまま貼る | AIコード安全公開の入口 |
GitHubは公開サーバーではなく「履歴の置き場」
初心者が特に混同しやすいのが、GitHubと本番サーバーの違いです。GitHubへpushするとコードの履歴は保存されますが、ロリポップやエックスサーバーなどで公開している本番サイトが自動で更新されるとは限りません。
役割を分けて考える
- Git:自分のPCで変更履歴を記録する道具
- GitHub:履歴を保存し、共有する場所
- GitHub Pages:HTML/CSS/JavaScriptを公開できる静的サイト用の機能
- レンタルサーバー:PHPやDBを含む本番サイトを動かす場所
- FTPやデプロイ:ローカルの変更を本番サーバーへ送る作業
PHPサイトや問い合わせフォーム、DB接続があるサイトは、GitHub Pagesではそのまま動きません。静的サイトとPHPサイトの使い分けは、GitHub Pagesで公開する方法で確認できます。
GitHubの具体的な使い道ベスト3【初心者向け】
理屈は分かったけど、実際にどう使うの?という方のために、初心者がGitHubを使うべき3つの具体的なシーンと、そのための基本コマンドをご紹介します。
1. 個人のプロジェクトを安全に保管・管理する(バックアップ&タイムマシン)
自分で作ったポートフォリオサイトや、学習中のコードを管理するのに最適です。パソコンが壊れても、GitHubにさえ残っていればデータは安全です。
まずは、自分のPCでプロジェクトのバージョン管理を開始します。この一連の流れを「ローカルリポジトリの作成」と呼びます。
ステップ1: バージョン管理の開始
プロジェクトフォルダで、Gitの監視を開始するコマンドです。「ここをGitの管理対象にするぞ!」と宣言するイメージです。
git init
ステップ2: 変更をセーブの準備
次に、どのファイルをセーブポイントに含めるかを選びます。 `.` は「すべてのファイルとフォルダ」を意味します。これを「ステージング」と呼びます。
git add .
ステップ3: セーブポイントの作成
ステージングしたファイルを、メッセージ付きでセーブ(コミット)します。`-m`に続くメッセージは「何を変更したか」が分かるように具体的に書くのがコツです。
git commit -m "最初のバージョンを作成"
ここまでの作業で、あなたのPC内にプロジェクトのセーブポイントが作成されました。次に、このデータをGitHub上にアップロード(バックアップ)します。GitHub上で保存場所となる「リモートリポジトリ」を作成した後、以下のコマンドを実行します。
ステップ4: ローカルとリモートを接続
あなたのPCのプロジェクトと、GitHub上の保存場所を紐付けます。URLはGitHubでリポジトリを作成した際に表示されるものをコピー&ペーストします。
git remote add origin https://github.com/あなたのユーザー名/あなたのリポジトリ名.git
ステップ5: GitHubへアップロード
ローカルPCで作成したセーブポイント(コミット)を、GitHubにアップロード(プッシュ)します。これで初めて、インターネット上にあなたのコードがバックアップされます。
git push -u origin main
2. チームでの共同作業をスムーズに進める(共同開発の拠点)
複数人で1つのウェブサイトを作る場合、GitHubは絶大な効果を発揮します。誰が・いつ・どこを修正したかが一目瞭然になり、「うっかり人のファイルを上書きしちゃった!」という事故を防ぎます。
ステップ1: プロジェクトのダウンロード
他の人が作ったGitHub上のプロジェクトを、自分のPCに丸ごと複製(クローン)してきます。共同作業はここから始まります。
git clone https://github.com/誰かのユーザー名/誰かのリポジトリ名.git
ステップ2: 最新の状態を取得
作業を始める前に、他のメンバーが更新した最新版のデータをGitHubから取ってきます(プル)。これを習慣づけることで、コンフリクト(変更の衝突)を減らせます。
git pull origin main
共同作業では、「ブランチ(Branch)」という機能が非常に重要です。これは、メインのコードに影響を与えずに、新しい機能の追加やバグ修正を試すための「作業用のコピー」のようなものです。自分の作業は必ずブランチを切ってから行い、完成したらメインに合流(マージ)させるのが基本の流れです。
ステップ3: 新しい作業用のブランチを作成
例えば「新しいヘッダーデザイン」の作業をするためのブランチを作成します。
git branch feature/header-redesign
ステップ4: 作成したブランチに移動
これから行う作業が、新しいブランチに記録されるように切り替えます。
git checkout feature/header-redesign
この後、コードを修正し、コミットし、自分のブランチをGitHubにプッシュします。そしてGitHub上で「プルリクエスト」を作成し、他のメンバーにレビューを依頼します。レビューでOKが出たら、変更がメインのコードに無事マージされる、という流れです。
3. 自分のスキルを証明する(ポートフォリオ公開)
Webクリエーターにとって、GitHubのプロフィールは**最高の履歴書兼ポートフォリオ**になります。あなたがどんなコードを書き、どんなプロジェクトに貢献してきたか(これを「草を生やす」と言ったりします)を、世界中の企業や開発者に見せることができます。
さらに、「GitHub Pages」という機能を使えば、作成したリポジトリを無料でWebサイトとして公開できます。HTML/CSS/JavaScriptだけで作られた静的なサイトであれば、サーバーを契約しなくても、`ユーザー名.github.io`というURLで全世界にあなたの作品を公開できるのです。これは、ポートフォリオサイトを公開する上で非常に便利な機能です。
PublicとPrivateはどう選ぶ?
GitHubリポジトリを作る時は、公開範囲を先に決めます。迷った場合、学習初期や本番サイトのコード管理ではPrivateから始めるほうが安全です。
| 公開範囲 | 向いているもの | 注意点 |
|---|---|---|
| Public | 公開してよいサンプル、ポートフォリオ、OSS | 世界中から見える。秘密情報は絶対に入れない |
| Private | 個人サイト、学習途中、PHPサイト、本番設定を含む可能性があるもの | 招待した人だけ見られるが、秘密情報は別管理が基本 |
ロリポップなどで運営しているPHPサイトでは、DB接続情報、FTP情報、管理画面メモなどが混ざりやすいため、まずPrivateで作り、.gitignoreで除外設定を整えてから運用するのが現実的です。
これだけは気をつけて!よくある誤解と注意点
最後に、初心者が特に注意すべき点をいくつか紹介します。
- 「コミットしたから安心」は間違い
git commitは、あくまで自分のPC内にセーブしただけです。GitHubにアップロードするには、必ずgit pushが必要です。「コミットしたのにGitHubに反映されてない!」というのは、プッシュ忘れがほとんどです。 - 公開範囲を意識しよう
リポジトリには「Public(公開)」と「Private(非公開)」があります。学習中のコードや、まだ見せたくないものはPrivateリポジトリで管理しましょう。(現在は無料アカウントでもPrivateリポジトリを無制限に作成できます) - 機密情報は絶対に入れない!
データベースのパスワードや、APIキーといった秘密の情報を、誤ってGitHubにプッシュしないように細心の注意を払いましょう。一度Publicリポジトリに上げてしまうと、世界中に公開されてしまい、悪用される危険があります。
このような機密情報を誤ってアップロードしないために、「.gitignore」というファイルを使います。このファイルに記述したファイルやフォルダは、Gitの管理対象から除外され、コミットやプッシュに含まれなくなります。
.gitignoreの記述例:
# Node.jsの依存関係フォルダ
node_modules/
# 環境変数を定義したファイル
.env
# 秘密のキーが書かれたファイル
secret_keys.txt
まとめ:GitHubは怖くない!Web制作者の必須ツール
GitHubは、単なるコード置き場ではありません。あなたの制作活動を守り、チームの連携を助け、そしてあなたのスキルを世界にアピールするための強力なプラットフォームです。
最初は黒い画面やコマンドに戸惑うかもしれませんが、今回紹介した基本的な使い方をマスターするだけで、あなたの開発効率と安全性は飛躍的に向上します。まずは自分のポートフォリオサイトを管理することから始めて、少しずつGitHubと仲良くなっていきましょう!
FTPで公開している個人サイトにもGitHubは使える
ロリポップへFileZillaやWinSCPでアップロードしているサイトでも、GitHubはバックアップと変更履歴として役立ちます。GitHubで公開することと、ロリポップへFTPで公開することは別の作業です。
| 場所 | 役割 | 注意点 |
|---|---|---|
| ローカルPC | VSCodeで編集する作業場 | まずここで構文チェックする |
| GitHub | 履歴とバックアップ | 秘密情報を入れない |
| ロリポップ | 実際に公開される本番サイト | 必要なファイルだけFTPで上げる |
GitHubにpushしただけでは、ロリポップの本番サイトは変わりません。最後にFTPアップロードして、本番URLで確認するところまでが公開作業です。
AIやCodexにGitHub運用を相談するメモ
GitHubの設定やpush、clone、公開前確認をAIへ相談する時は、実在する秘密情報を貼らず、作業環境と困っている状態だけを整理して渡します。
GitHubとサイト運用について相談します。
目的:
- 初回push / clone / pull / ブランチ作業 / 公開前確認 / 戻し方 のどれか:
環境:
- Windows / macOS / Linux:
- ローカル作業フォルダ:
- 公開サーバー:
- GitHub Pagesを使う予定: あり / なし / 分からない
今の状態:
- git status の結果:
- git remote -v の結果:
- エラー文:
- 本番サイトへアップロード済みか:
確認したいこと:
- GitHubに上げてよいファイルか
- pushしてよい状態か
- clone後に足りないファイルがあるか
- 本番へアップロードするファイルとGitHubへ上げるファイルの違い
- 失敗した時の戻し方
貼らない情報:
- DBパスワード、APIキー、FTPパスワード
- 管理画面URL、ログイン情報
- privateリポジトリの招待情報や個人情報
最初に決める安全ルール
- 公開リポジトリにする前に、DBパスワードやFTP情報がないか確認する
.gitフォルダはロリポップへアップロードしない- 作業前に
git status、公開前にPHP構文チェックを行う - 記事を統合したら、古いURLは削除より301リダイレクトを優先する
初心者が最初に読む順番
GitHubは機能が多いので、最初から全部覚える必要はありません。個人サイト運営や学習なら、次の順番で進めると迷いにくいです。