GitHubとGit: 違いと関係をわかりやすく解説

GitとGitHubは混同されがちですが、役割の異なるものです。Gitは自分のコンピュータにインストールするバージョン管理ツールで、プロジェクトの保存された状態を記録し、いつでもそこに戻れるようにします。GitHubはGitリポジトリのコピーを保存するWebサービスで、その周囲にチーム開発のための機能が用意されています。覚え方は、Gitが「エンジン」、GitHubはそのエンジンを載せられる「ガレージ付きのサービス」だと考えるとわかりやすいでしょう。

Gitとは

Gitは分散型のバージョン管理システムです。2005年にLinus Torvaldsが Linuxカーネルの開発のために作成し、現在では業界標準になっています。Gitは基本的にローカルで動作します。変更履歴はプロジェクト内の隠しフォルダ .git に保存されるため、多くの操作にインターネット接続は必要ありません。

「分散型」であることが重要なポイントです。プロジェクトに参加している人は全員、履歴をすべて含んだリポジトリの完全なコピーを自分のコンピュータに持っています。最新のファイルだけでなく、履歴全体がコピーされています。サーバーが壊れても、どの作業用マシンからでもプロジェクトを復元できます。

Git単体でできること:

• 変更をコミット（作成者・日時・説明を持つプロジェクトのスナップショット）として記録する
• 誰がいつ、なぜ特定の行を変更したかを確認する（git log、git blame）
• ブランチで並行した開発の流れを管理し、統合する
• ほかの作業を失わずに、ミスを取り消す
• git push、git pull、git fetch を使って、ほかのリポジトリと履歴をやり取りする

Gitはコマンドラインのツールです。GUIクライアントやエディタ内蔵のパネル（VS Code、IntelliJ IDEAなど）は、同じコマンドを呼び出すラッパーにすぎません。

GitHubとは

GitHubはGitリポジトリをホスティングするクラウドプラットフォームで、現在はMicrosoftが運営しています。ローカルのコードを git push で送信すると、チームメンバーや採用担当者、リポジトリが公開されていればインターネット上の誰にでも見られる状態になります。

GitHubの価値は保存だけではありません。Gitそのものにはない、次のような機能が加わります。

• プルリクエスト: ブランチの統合を依頼し、行単位のコードレビューとともに議論する仕組み
• Issues: プロジェクトに紐づいたタスクやバグ報告
• GitHub Actions: CI/CDとして、pushのたびにテスト、ビルド、デプロイを自動実行する
• アクセス管理: 誰が読み取り、書き込み、保護されたブランチへマージできるかを管理する
• 開発者プロフィール: 活動の履歴や公開プロジェクトが、採用担当者の目に触れる
• GitHub Pages: リポジトリから直接、静的サイトを無料で公開できる

「git hub」や「github とは」と検索する人の多くは、このサービス（github.com）を指しています。Git本体の公式サイトは git-scm.com で、インストーラーもそこからダウンロードできます。

GitとGitHubの比較表

GitとGitHubの連携の仕組み

両者をつなぐのがリモート（remote）、つまりリモートリポジトリです。ローカルリポジトリは、GitHub上のリポジトリのアドレスを、通常は origin という短い名前で保存しています。やり取りは次の3つのコマンドで行います。

• git push: 自分の新しいコミットをサーバーへ送信する
• git fetch: 他の人のコミットをダウンロードする（自分のファイルは変更しない）
• git pull: 変更をダウンロードし、現在のブランチへ即座に統合する（実質は fetch と merge または rebase）

重要なのは、GitHubはあなたのコードを、送信するまで認識しないということです。コミットは git push するまでローカルにしか存在しません。初心者が「コミットしたのにGitHubに何もない」と困る原因はここにあります。

ローカルのプロジェクトをGitHubに載せる流れ

# 1. ローカルでリポジトリを作成する
cd my-project
git init
git add .
git commit -m "最初のコミット"

# 2. github.com で空のリポジトリ（READMEなし）を作成し、
#    そのアドレスをremoteとして登録する
git remote add origin git@github.com:username/my-project.git

# 3. ブランチ名をmainに変更して送信する
git branch -M main
git push -u origin main

-u（正式には --set-upstream）は、ローカルの main ブランチとリモートのブランチを関連付けます。以後は引数なしで git push と git pull を実行できます。

逆の流れ: GitHubのリポジトリから始める

プロジェクトがすでにGitHubにある場合は、新しく作るのではなくクローンします。

git clone https://github.com/username/my-project.git
cd my-project

このコマンドで履歴全体がダウンロードされ、remote origin も自動的に設定されます。

認証: SSHかHTTPSか

2021年以降、GitHubはGitのHTTPS接続でアカウントのパスワードを受け付けなくなりました。使える方法は2つです。

HTTPS + Personal Access Token。 トークンはアカウント設定（Settings → Developer settings）で作成し、パスワードの代わりに入力します。毎回入力しないように、Gitは資格情報マネージャーを使います。Windowsでは Git for Windows に含まれています。

SSHキー。 採用担当者も設定できることを期待する方法です。

# キーを生成する
ssh-keygen -t ed25519 -C "you@example.com"

# 公開鍵を表示し、GitHubに登録する
# Settings → SSH and GPG keys → New SSH key
cat ~/.ssh/id_ed25519.pub

# 接続を確認する
ssh -T git@github.com

成功すると、GitHubがユーザー名入りのあいさつを返し、シェルアクセスは提供されないという説明が表示されます。これは正常です。この場合のリポジトリのアドレスは https:// ではなく git@github.com:user/repo.git の形式を使います。

すでにHTTPSで接続しているリポジトリは、次のコマンドでSSHに切り替えられます。

git remote set-url origin git@github.com:username/my-project.git

GitHub、GitLabなどの違い

GitHubはGitのホスティングサービスの1つにすぎません。どのサービスも同じGitを使うため、履歴を失わずにリポジトリを移行できます。違いは、コードの周辺で提供される機能です。

GitLabでは統合依頼を merge request、GitHubでは pull request と呼びますが、役割は同じです。ブランチの変更を提案し、統合の前に議論します。呼び名は違っても、Gitのコマンドは共通です。

1つのローカルリポジトリに複数のremoteを登録し、GitHubとGitLabの両方にミラーすることもできます。

git remote add gitlab git@gitlab.com:username/my-project.git
git push gitlab main
git remote -v

一人で作業するならGitHubは必要か

技術的には不要です。Gitはローカルだけでも十分に動作します。ただし、一人のプロジェクトでもリモートリポジトリには3つの大きな利点があります。

• バックアップ: ノートPCが壊れても、コードと履歴はサーバーに残ります。
• 複数デバイスでの作業: 自宅と職場の間で push と pull を使って同期できます。
• ポートフォリオ: ジュニア職の選考では、履歴書より先にGitHubのプロフィールを見られることがよくあります。動いているプロジェクト、わかりやすいコミットメッセージ、READMEがあるかが見られます。

初心者が学ぶ順番

GitとGitHubを同時に覚える必要はありません。順番が大切です。まずはローカルでの基本的な流れを身につけましょう。git init、git status、git add、git commit、git log、ブランチ、マージです。これらを見ずに使えるようになったら、GitHubに登録し、SSHを設定して push、pull、fetch を試します。最後に、チームでの作業手順、つまりフォーク、タスクごとのブランチ、プルリクエスト、レビューを学びます。

採用担当者がGitHubで見るポイント

緑色の草グラフは重要ではありません。経験のあるレビュアーは、数分で次のような点を確認します。

• 「fix」「123」「修正」ではなく、わかりやすいコミットメッセージになっているか
• 「プロジェクトを追加」のような1つの巨大なコミットではなく、小さく論理的なコミットになっているか
• プロジェクトの起動方法を説明したREADMEがあるか
• .gitignore があり、node_modules、パスワードを含む .env、IDEのファイルがリポジトリに入っていないか
• 学習用のプロジェクトでも、ブランチとプルリクエストを使っているか。チームでの作業手順に慣れていることがわかります。

初心者によくあるエラー

「fatal: not a git repository」

リポジトリの外でGitのコマンドを実行しています。プロジェクトのフォルダに移動するか、git init を実行してください。これはGitのローカルなエラーで、GitHubのアカウントとは無関係です。

「Permission denied (publickey)」

SSHキーが作成されていない、GitHubに登録されていない、またはssh-agentに読み込まれていない状態です。ssh -T git@github.com とアカウント設定のキー一覧を確認してください。

push時の「rejected … (fetch first)」

サーバーには、あなたのローカルにないコミットがあります。たとえば、READMEを含めてGitHubでリポジトリを作成した場合です。先に変更を取り込みます: git pull --rebase origin main。その後、git push をやり直してください。どの作業を上書きするかわからない場合は、--force を使わないでください。

公開リポジトリに含まれた秘密情報

一度コミットに入ったパスワードやAPIキーは、ファイルを後で削除しても履歴に残ります。そのキーは直ちに再発行してください。また、.env は事前に .gitignore に追加しておきましょう。

まとめ

Gitは自分のコンピュータで動くバージョン管理ツール、GitHubはそのリポジトリをクラウドに置き、チーム開発の機能を加えたサービスです。GitLabやBitbucketなどはGitHubの代替サービスであり、Gitの代替ではありません。すべて同じコミット、ブランチ、コマンドを使っています。まずローカルのGitから始め、その後リモートを設定し、SSHを構成しましょう。ローカルリポジトリとGitHubの連携、push、pull、fetchは、Gitのコースで実際に試しながら学べます。