結論：Gitはあなたのパソコンの中で変更履歴を記録する「道具（バージョン管理ソフト）」、GitHubはそのGitで作った履歴をインターネット上に置いて他の人と共有する「場所（ホスティングサービス）」です。 Gitはインストールしなくても使い方だけなら学べますが、GitHubはGitの上に「共有」と「レビュー」の機能を足したサービスだと考えると混同しません。
そもそも「別のもの」だと知らないと詰まる
「Git と GitHub 違い」で検索する人の多くは、名前が似ているせいで「同じもののこと？」「片方だけ覚えれば十分？」と迷っています。答えはシンプルで、Gitはソフトウェア、GitHubはそのソフトウェアを使ったサービスの一つです。
- Git：1974年生まれのプログラマーLinus Torvaldsが作った、変更履歴を記録するためのソフトウェア。ネットに繋がっていなくても、自分のパソコンの中だけで完結して使えます。
- GitHub：Gitのリポジトリ（履歴の入れ物）をインターネット上に置いて、他の人と見せ合ったり、送り合ったりできるようにしたWebサービス。GitHub以外にもGitLabやBitbucketといった同種のサービスがあります。
つまり「Gitを覚える」と「GitHubを使う」は別の話です。Gitの操作（記録する・枝分かれさせる・合流させる）を体で覚えるところから始めるのが近道で、Gitコースの最初のレッスン 「バージョン管理とは ― git init」 は、インストールも登録も不要でブラウザ内のシミュレータにコマンドを打つだけで試せます。
Gitでできること ― 自分のPCの中で完結する記録
Gitは「今の状態」をスナップショットとして残していく仕組みです。ネットワークが一切なくても、次の一連の操作だけでバージョン管理は成立します。
git initでリポジトリを作る（git-01）- ファイルを編集し
git statusで状態を確認する（git-03） git addで次の記録に含める変更を選ぶ（git-04）git commitで記録を確定する（git-05）git logで履歴をたどる（git-06）
さらに、実験用の枝を作って本流を壊さずに試す git branch（git-09）や、枝を合流させる git merge（git-12）も、すべて自分のパソコンの中だけの操作です。ここまではGitHubのアカウントが一つもなくても成立します。この一連の使い方の手順は 「Git使い方入門｜add・commit・pushとは？」 に詳しくまとめているので、コマンドの意味から知りたい人はそちらを先に読んでください。
GitHubでできること ― Gitの履歴を「共有」する
GitHubが足すのは、この記録をインターネット越しに送り合う仕組みと、送り合ったコードをレビューする仕組みです。
- リモート：インターネット上に置かれたリポジトリの控え。まずローカルに「送り先」を登録します（「リモートとは ― git remote add」）。
- push：ローカルに積み上げたコミットをリモート（GitHubなど）へ送る（「git push ― リモートへ送る」）。
- clone / pull：逆に、リモートのリポジトリを丸ごと受け取ったり、他人の最新の変更を取り込んだりする（「clone と pull ― 受け取る側の操作」）。
- プルリクエスト（Pull Request）：
mainに直接反映せず、変更をレビューしてもらってから取り込む、GitHubの中心的な機能（「GitHub とプルリクエスト」）。
つまりGitHubは、Gitというソフトの機能ではなく、Gitのリポジトリを預かって共有・レビューをやりやすくする外部サービスです。GitHubが無くてもGitは使えますし、逆にGitの仕組みを理解していないとGitHubの「push」や「pull request」が何をしているのか実感が持てません。この順番（Gitの操作 → GitHubでの共有）で学ぶのが遠回りに見えて一番早いです。
つまずきポイント：「push すればGitHubに登録される」と思ってしまう
初心者がよく誤解するのが、「Gitを使い始めた時点で自動的にGitHub上にも何か残る」という感覚です。実際は逆で、git commit はあくまでローカルの記録であり、git remote add で送り先（origin）を登録し、git push を実行して初めてGitHub側に反映されます。この2ステップを踏まなければ、コミットはあなたのパソコンの中だけに存在し続けます。
この違いは 「リモートとは ― git remote add」 と 「git push ― リモートへ送る」 を実際にブラウザで打ってみると、「ローカルの記録」と「リモートへの送信」が別の操作だと体感できます。用語をさらに短く確認したいときは Wikiの「Gitとは」・「GitHubとは」・「リポジトリとは」 も参照してください。
チーム開発での使い分けの全体像
実務での一日の流れを見ると、GitとGitHubがどう役割分担しているかがはっきりします。
- main を直接いじらず、ブランチを切る（Gitの機能）
- こまめにコミットする（Gitの機能）
- push してプルリクエストを作る（GitHubの機能）
- レビューを受け、承認されたらマージする（GitHubの機能）
この一連の型は 「チーム開発フローの全体像」 にまとめてあり、Gitの操作とGitHub上での操作がどこで切り替わるかが分かります。合流の際に他の人と同じ場所を変えていると衝突（マージコンフリクト）が起きますが、これはGitHub固有の問題ではなくGit自体の仕組みなので、「マージコンフリクト ― 衝突を解決する」 で先に慣れておくと安心です。用語は Wikiの「マージコンフリクトとは」、GitHub側のレビューの仕組みは Wikiの「プルリクエストとは」 も参照してください。
次に読む
- Gitコースのトップページ — 「Gitをはじめる」→「ブランチとマージ」→「履歴を整える」→「リモートと共同作業」→「CI/CDとGitHub Actions」の全5章29レッスン。
git push（git-21）までは第1〜3章に加えて第4章の途中までブラウザで実際にコマンドを実行でき、clone/pull・プルリクエスト以降のチーム開発フローとCI/CD（第4章後半〜第5章）は読み物として学べます。 - Git使い方入門｜add・commit・pushとは？初めてのコミットまで — Gitそのものの使い方を最初のコミットまで手順で知りたい人はこちら。
- Wikiの「コミットとは」 / 「ブランチとは」 — 用語をさらに確認したいときに。
- プログラミング独学、何から始める？ — Git・GitHub以前に何を学ぶか迷っている人はこちら。